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PREFACE 


This  report  was  prepared  by  the  Institute  for  Defense  Analyses  (EDA)  for  the  Office 
of  Engineering  Technology,  Deputy  Under  Secretary  (Research  and  Advanced 
Technology),  and  the  US  Army  Armament  Research,  Development,  and  Engineering 
Center,  under  Contract  Number  MDA  903  89  C  0003,  Task  Order  T-D6-553, 
"Applications  of  Systems  Engineering  Requirements  to  Development  of  a  Unified  Life 
Cycle  Environment" 

The  issuance  of  this  report  satisfies  subtask  (4):b:iv,  "Prepare  a  historical  draft 
report  with  emphasis  on  the  General  Dynamics  Convair  Division  RAMCAD'  contract. 
The  report  will  be  in  three  parts: 

1.  IDA  perspective  from  the  contract  start  (September  14,  1987)  until 
September  31,  1988. 

2.  IDA  perspective  from  September  31,  1988  through  August  1, 1989. 

3 .  Recomendations  for  future  directions  and  work  in  support  of  the  ARDEC  goals 
for  a  future  RAMCAD  System." 

This  paper  was  reviewed  by  Dr.  Joel  Tumarkin,  a  consultant  to  IDA. 
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I.  INTRODUCTION 


A.  INTRODUCTION 

RAMCAD  is  the  acronym  for  Reliability  and  Maintainability  in  Computer-Aided 
Design.  The  goal  of  RAMCAD  programs  is  to  design  reliability  and  maintainability  into  a 
product  rather  than  to  accept  these  characteristics  as  by-products  of  a  design  driven  largely 
by  performance  criteria.  Field  support  costs  are  considered  in  all  design  efforts. 
Historically  these  costs  have  been  a  secondary  consideration  in  the  design  of  military 
systems  and  are  not  actively  balanced  against  performance  requirements.  The  goal  of 
RAMCAD  is  to  provide  software  programs  that  can  be  used  in  the  design  process  to  make 
an  active  trade-off  possible.  The  aim  is  to  reduce  design  errors  which  lead  to  the  expensive 
"test  and  Fix"  methods  in  common  use  by  the  Department  of  Defense  (DoD),  or,  if  rework 
is  not  feasible,  result  in  unnecessarily  high  support  costs  for  the  field  equipment 

A  working  definition  of  RAMCAD  is  the  use  of  computer-aided  design  technology 
to  continually  assess  and  improve  the  reliability  and  maintainability  (R&M)  characteristics 
of  a  product  throughout  its  design  cycle. 

B .  EARLY  HISTORY 

In  1981,  the  Defense  Science  Board  issued  a  report  on  the  operational  readiness  of 
high  performance  systems  [Ref.  1].  The  board's  major  recommendations  were  to  design 
reliability  into  the  system  from  the  initial  design  efforts  and  to  mature  that  capability  prior  to 
full-rate  production.  This  recommendation  captured  the  attention  of  the  Director  of  the 
Weapon  Systems  Support  Improvement  Group1  at  OSD,  who  was  charged  with  ensuring 
that  R&M  issues  were  properly  addressed  during  the  full-scale  engineering  development  of 
new  weapon  systems. 


1  Mr.  Russell  Shorey. 
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The  Director  approached  the  Institute  for  Defense  Analyses  (IDA)  with  a  task  to 
assess  the  impact  of  new  technology  on  the  R&M  of  future  weapon  systems.  As  a  result, 
an  18-month  study  of  this  problem  was  undertaken.  The  study  focused  on  case  studies  of 
current  weapon  systems  and  studies  of  the  potential  impact  of  new  technologies.  Six 
weapon  systems  and  sixteen  technology  areas  were  selected,  and  a  working  group  was 
formed  for  each.  Each  working  group  met  monthly  for  six  to  eight  months  and  produced  a 
report  on  its  subject  area.  The  documentation  was  summarized  in  a  four-volume  report  that 
included  an  Executive  Summary,  a  Core  Group  Report,  a  Case  Study  Analysis,  and  a 
Technology  Steering  Group  Report  [Ref.  2]. 

Following  the  extensive  study,  which  produced  a  multitude  of  recommendations, 
IDA  undertook  an  analysis  to  identify  key  lines  of  attack  on  the  R&M  problem.  This  study 
was  sponsored  jointly  by  the  Director  of  the  Weapons  System  Support  Improvement 
Group  and  the  Director  of  the  Engineering  Systems  Group  in  the  Research  and  Advanced 
Technology  Office.2  The  latter  oversees  all  of  the  DoD  technology  base  R&D  programs 
that  deal  with  platforms  and  their  weapons. 

Two  approaches  emerged  from  this  effort.  The  first  plan  was  to  address  the 
benefits  and  the  problems  involved  in  replacing  the  massive  paperwork  that  defines  the 
operating  and  support  needs  of  a  modem  weapon  system  with  digitized  data  derived 
directly  from  the  prime  contractor's  computer-aided  design/computer-aided  manufacturing 
(CAD/CAM)  systems.  The  plan  was  based  on  the  concept  that  information  age  technology 
could  reduce  the  workload  associated  with  handling  the  extensive  engineering  and  technical 
data  needed  to  support  a  weapon  system.  Current  technology  could  also  be  used  to  vastly 
reduce  the  problems  of  updating  this  information  by  providing  a  single-point-of-entry 
system  for  the  continuous  flow  of  design  changes  that  occur  due  to  engineering 
modifications. 

The  formidable  task  of  evolving  a  plan  to  address  this  problem  was  undertaken  by 
an  ad  hoc  DoD- Industry  Working  Group  on  Computer-Aided  Logistics  Support  (CALS), 
formed  under  the  auspices  of  IDA.  This  group  coined  the  acronym  CALS  to  describe  its 
efforts  and,  in  an  intensive  series  of  meetings  involving  more  than  80  people  (including 
subgroups)  over  7  months,  produced  a  5-year  plan  for  evolving  a  completely  digitized 
logistics  system.  They  also  made  recommendations  as  to  how  the  plan  could  be 


2  Mr.  Ray  Siewert. 
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implemented  [Ref.  3].  These  recommendations  were  eventually  approved  by  the  Deputy 
Secretary  of  Defense.  Appendix  C  contains  an  Executive  Summary  of  the  initial  CALS 
Implementation  Plan. 

The  second  approach  that  emerged  from  the  IDA  analysis  of  the  R&M  study  was  to 
address  how  the  design  process  might  be  modified  to  obtain  a  better  balance  between  R&M 
needs  and  other  performance  requirements.  Concurrent  with  the  CALS  working  group 
effort,  an  IDA  study  of  this  problem  was  initiated  by  the  Air  Force  Human  Resources 
Laboratory  through  the  Office  of  the  Secretary  of  Defense  (OSD)  Weapon  System  Support 
Improvement  Group.  IDA  assembled  an  ad  hoc  tri-Service  group  from  the  R&D 
community,  chaired  by  the  Air  Force  to  guide  the  study,  which  became  known  as  the 
RAMCAD  study.  About  8  months  after  this  tri-Service  group  began  work,  it  became  a 
Joint  Logistics  Commanders  (JLC)  Subcommittee  on  RAMCAD,  reporting  to  the  JLC 
Logistics  R&D  Committee.  The  study  at  IDA  continued,  and  eventually  led  to  the  letting  of 
contracts  with  Joint  Service  support  for  the  development  of  RAMCAD  software,  which  is 
described  in  the  following  section. 

At  this  point,  an  explanation  of  the  relationship  of  CALS  to  RAMCAD  is 
appropriate.  The  CALS  working  group  addressed  the  formation  of  digital  data  and  its 
distribution  through  the  logistics  system.  In  addressing  the  formation  of  the  digital  data  in 
the  prime  contractor’s  CAD/CAM  system,  the  CALS  group  recommended  that  reliability 
and  maintainability  analyses  be  incorporated  into  the  design  system.  One  major 
recommendation  of  the  CALS  group  was  that  RAMCAD  be  implemented  by  contractors  as 
soon  as  possible  [Ref.  3]. 

Interest  in  CALS  has  grown  quickly.  Each  of  the  Services  now  has  a  CALS  office 
to  coordinate  internal  activities,  and  each  of  these  offices  has  some  degree  of  interest  in 
RAMCAD.  The  main  thrust  of  the  Service  CALS  efforts  seems  to  have  been  directed  at 
transferring  digital  data  into  their  logistics  systems  and  distributing  it  efficiently.  More 
recently,  however,  interest  in  improving  the  design  process  to  create  a  higher  quality 
product  has  grown.  The  Air  Force's  Unified  Life  Cycle  Engineering  (ULCE)  initiative, 
various  DoD  programs,  and,  most  recently,  OSD's  Concurrent  Engineering  initiative  are  all 
focused  on  improving  the  design  process.  The  CALS  office  at  OSD  recognized  that  their 
interest  in  design  extended  beyond  RAMCAD  to  other  supportability  and  producibility 
issues.  To  reflect  this  broader  view,  the  acronym  CALS  was  expanded  from  Computer- 
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Aided  Logistics  Support  to  Computer-aided  Acquisition  and  Logistics  Support  The  CALS 
Service  offices  have  recently  expanded  their  interests  to  include  concurrent  engineering. 

C .  EVOLUTION  OF  THE  RAMCAD  SOFTWARE  DEVELOPMENT 
PROGRAM 

From  1984  to  1986,  the  R&M  efforts  within  DoD  had  two  main  thrusts.  One  was 
to  evolve  a  research  and  development  (R&D)  program  plan  that  could  be  used  by  the  tri- 
Service  group  to  accelerate  the  introduction  of  RAMCAD  into  use  by  defense  contractors. 
The  other  was  to  track  the  evolution  of  R&M  analysis  tools  by  vendors  and  to  understand 
contractors'  attitudes  about  using  these  tools  to  develop  weapon  systems. 

The  initial  effort  to  develop  an  R&D  program  focused  very  quickly  on  the  need  for 
a  computer-based  solution  as  it  would  offer  the  flexibility  they  perceived  was  needed. 
Most  defense  contractors  used  computers  (commonly  called  workstations)  in  their  design 
offices.  The  development  of  a  computer  software  tool  that  would  integrate  R&M  analysis 
tools  and  be  available  during  the  design  process  was  the  goal.  The  combination  of  the 
proposed  software  and  computer  became  known  as  the  RAMCAD  workstation.  The 
question  of  how  to  pursue  such  a  development  went  through  numerous  iterations.  A  two- 
phase  approach  was  generally  agreed  upon.  Phase  I  was  to  involve  creating  a  RAMCAD 
workstation  using  existing  commercial  R&M  analysis  tools.  This  workstation  would 
demonstrate  the  ability  to  rapidly  access  R&M  analyses  and  apply  them  to  design  data 
acquired  directly  from  a  CAD/CAM  or  computer-aided  engineering  (CAE)  system.  The 
goal  of  Phase  II  was  to  upgrade  this  prototype  using  new  software  and  new  technology  as 
appropriate.  This  two-phase  approach  eventually  translated  into  Tasks  I  and  II  of  the 
Program  Research  and  Development  Announcement  (PRDA)3  that  was  eventually  issued 
by  the  Air  Force. 

Another  issue  addressed  in  developing  the  program  plan  was  whether  to  assign  the 
lead  role  in  the  R&D  program  to  a  university  or  a  contractor.  A  university-centered 
consortium,  which  would  involve  a  number  of  contractors,  with  the  university  serving  as 
integrator  as  well  as  providing  innovative  ideas  for  Phase  II,  was  somewhat  appealing.  A 
number  of  possibilities  for  such  consortia  were  investigated  with  universities  across  the 


3  The  full  context  of  this  announcement  is  contained  in  Appendix  A. 
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country.  None  of  these  came  to  fruition,  mainly  because  the  universities  were  unwilling  to 
accept  the  strict  contractual  requirements  that  the  Services  felt  necessary. 

IDA,  who  was  tasked  to  assist  the  tri-Service  group  in  the  development  of  a 
RAMCAD  development  plan,  continued  to  pursue  its  development.  As  an  adjunct  to 
developing  the  R&D  plan,  some  specific  aspects  of  a  RAMCAD  workstation  were 
investigated  in  small,  narrowly  focused  subtasks  given  by  IDA  to  the  University  of 
Maryland,  Boeing,  and  TRW. 

University  of  Maryland 

The  University  of  Maryland  effort,  the  largest  of  these  subtasks,  addressed  the 
practical  (rather  than  theoretical)  problems  of  integrating  thermal  and  wiring  analyses  of 
printed  circuit  board  designs  to  arrive  at  optimal  component  placements  from  a  reliability 
viewpoint  without  violating  wiring  rules  (Ref.  4].  An  unforeseen  resul'.'.  of  this  work  was 
the  conclusion  that,  in  some  cases,  modifications  to  commercially  available  analysis 
packages  would  have  to  be  made  to  integrate  them  into  an  optimization  scheme. 

The  work  at  Maryland  has  since  continued  with  other  sponsorship  and  led  to  the 
development  of  the  University  of  Maryland  Center  for  Computer-Aided  Life  Cycle 
Engineering  (CALCE).  The  CALCE  Center  is  an  industry/university  cooperative  research 
and  development  center  sponsored  by  the  National  Science  Foundation.  The  center's 
primary  focus  is  developing  new  techniques  for  designing  electronics  products  for 
reliability,  maintainability,  and  supportability.  CALCE  is  the  only  center  of  its  kind  in  the 
country  that  is  focusing  on  design  for  supportability  of  electronics.  A  number  of  major 
defense  electronics  suppliers  are  members  of  the  center,  including  Westinghouse,  Texas 
Instruments,  Digital  Equipment  Corporation,  Northrop,  General  Electric,  Allied  Signal, 
and  General  Dynamics. 

Boeing 

Another  aspect  of  the  RAMCAD  workstation  was  investigated  by  Boeing.  The 
Boeing  subtask  involved  exploring  the  possible  use  in  RAMCAD  of  an  executive  controller 
computer  program  they  had  developed  to  access  and  activate  analyses  programs  resident  at 
different  locations  on  a  network  [Ref.  5].  Boeing  was  able  to  demonstrate  the  ability  to 
send  and  receive  information  from  other  systems  on  the  same  network  that  had  performed 
tasks  requested  by  the  executive  controller.  This  exchange  and  processing  of  information 
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took  place  while  other  work  was  being  done  on  the  user's  system.  This  allowed  the 
maximum  use  to  be  made  of  other  computer  systems  on  the  network  while  leaving  the  user 
only  one  primary  system  to  be  concerned  with. 

TRW 

TRW  was  tasked  with  creating  a  rapid  prototype  of  a  RAMCAD  workstation  to 
scope  the  man-machine  interface  problems-to  determine  what  R&M  information  would  be 
needed,  and  in  what  format,  to  assist  the  designer  of  a  printed  circuit  board  [Ref.  6].  A 
prototype  interface  was  created  with  the  input  from  a  very  limited  group  of  designers.  A 
video  tape  of  the  prototype  was  produced  and  delivered  to  the  Air  Force. 

The  insights  from  all  three  of  these  subtasks  were  used  in  detailing  the  work  to  be 
done  in  developing  a  RAMCAD  workstation  prototype  [Ref.  7]. 

The  other  major  thrust  of  the  IDA  RAMCAD  study  was  to  monitor  pertinent 
developments  at  software  vendors  and  at  contractors  and  promote  interchange  of  ideas. 
Direct  contact  with  vendors  and  contractors  through  visits  and  telephone  conversations  and 
technical  interchange  meetings  (TIMs)  were  held  [Ref.  8].  Close  contact  was  maintained 
with  a  National  Security  Industrial  Association  (NSIA)  committee  investigating  RAMCAD 
issues  [Ref.  9]  in  the  avionics  industry,  and  a  RAMCAD  bulletin  was  published. 

Through  these  efforts,  it  became  clear  that  the  design  environment  was  rapidly 
changing.  Initially,  many  vendors  and  contractors  talked  of  support  for  RAMCAD  goals 
but  made  no  effort  to  support  RAMCAD.  By  the  end  of  1986,  however,  their  R&M 
activities  had  increased  substantially.  In  fact,  IDA  developed  a  catalog  of  R&M  software 
but  was  unsuccessful  at  keeping  it  current  because  of  the  rapidly  changing  nature  and 
amount  of  software  to  be  catalogued. 

From  this  monitoring  effort,  an  extensive  file  of  information  was  collected  and  a 
key -word-in-context  index  was  developed  to  make  it  easily  accessible.  This  information 
was  essential  in  forming  recommendations  for  the  tri-Service  group  concerning  the  detailed 
nature  of  the  R&D  program  plan  [Ref.  10]. 
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II.  THE  RAMCAD  SOFTWARE  DEVELOPMENT  PROGRAM 


A.  STRUCTURE 

To  implement  the  R&D  program  plan,  it  was  finally  decided  that  the  Air  Force 
would  take  the  lead  and  issue  a  PRDA4  indicating  an  interest  in 

•  The  development  of  a  prototype  RAMCAD  system  (Task  1) 

•  The  accomplishment  of  fundamental  research  in  this  area  (Task  2) 

•  The  development  of  an  engineering  curriculum  incorporating  RAMCAD 
(Task  3). 

The  PRDA  further  described  each  task  in  terms  of  subtasks. 

The  announcement  generated  an  unexpectedly  large  response.  Fourteen  proposals 
were  received  and  a  tri-Service  source  selection  board  was  assembled  in  July  1986.  As  a 
result  of  their  deliberations,  three  contractors  were  selected  as  most  responsive  to  the  intent 
of  the  PRDA,  mainly  TRW,  Boeing,  and  General  Dynamics.  A  protracted  series  of 
activities  to  allocate  the  funds  and  negotiate  contracts  then  followed.  TRW  was  under 
contract  in  early  1987,  but  the  contracts  with  Boeing  and  General  Dynamics  were  not 
signed  for  another  six  months.  The  Navy  was  unable  to  p:  ide  funds  so  the  funding 
responsibility  fell  to  the  Army  and  the  Air  Force.  The  Army  agreed  to  shoulder  the  initial 
cost  (first  two  years)  of  the  General  Dynamics  contract,  and  the  Air  Force  funded  the  TRW 
and  Boeing  contracts.  The  TRW  contract  was  the  only  one  that  covered  all  three  tasks; 
however,  it  was  eventually  terminated  because  the  Air  Force  could  not  meet  the  financial 
burden.  The  Air  Force  also  wanted  to  ensure  that  they  would  be  able  to  meet  their  financial 
commitment  to  the  Army  to  fund  the  final  two  years  of  the  General  Dynamics  contract.  The 
following  sections  describe  the  outcome  of  these  contracts.  The  GD  program  has  been 
closely  monitored  by  IDA  and  detailed  descriptions  of  that  work  follow  in  Chapter  in. 


4  Program  Research  and  Development  Announcement.  See  Appendix  A. 
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B  .  THE  TRW  CONTRACT 

1 .  Task  I 

TRW  was  to  develop  a  RAMCAD  prototype,  focusing  primarily  on  electronic 
design.  The  electronic  assembly  chosen  was  a  typical  frequency  synthesizer  for  an 
avionics  system.  The  actual  design  was  not  new;  it  had  been  used  in  teaching  engineering 
students.  In  recent  years,  the  majority  of  this  design  has  been  replaced  by  a  single 
integrated  circuit.  TRW  intended  to  develop  a  prototype  RAMCAD  system  using  a 
proprietary  development  system,  which  they  had  created,  that  allows  the  rapid  prototyping 
of  the  system  display  to  investigate  interactive  design  and  the  human  interface.  They 
planned  to  integrate  off-the-shelf  commercial  software  packages  that  would  be  operated  by 
an  executive  control  program  whose  display  would  be  developed  by  their  proprietary 
system. 

2 .  Task  II 

This  task  was  aimed  at  using  the  prototype  developed  under  Task  I  and  the  lessons 
learned  from  it,  to  develop  a  fully  functioning  system  that  would  be  useful  to  the 
engineering  community.  Because  this  task  involved  new  approaches  to  the  engineering 
process,  the  university  team  members  from  Task  HI  were  included  in  this  effort. 

3.  Task  III 

Task  HI  focused  on  finding  ways  to  influence  the  engineering  academic  community 
to  address  and  teach  a  more  complete  design  process.  TRW  selected  the  Virginia 
Polytechnic  Institute  (VPI)  as  the  subcontractor  to  perform  this  task. 

4.  Conclusions 

Due  to  a  lack  of  sufficient  DoD  funds,  the  TRW  contract  was  terminated 
prematurely  in  November  1987.  Thus  the  conclusions  derived  from  these  efforts  were 
limited. 

The  TRW  tasks,  while  limited  in  scope,  did  contribute  to  the  primary  goals  of 
RAMCAD.  TRW's  survey  and  analysis  of  the  reliability,  maintainability,  and 
supportability  (RM&S)  software  tools  available  to  the  engineer  and  the  discussion 
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following  their  survey  has  influenced  workstation  design.  Industry  has  moved  forward  in 
addressing  the  lack  of  software  and  the  need  for  integration  with  CAD  and  CAE  systems  in 
particular.  An  example  of  the  influence  on  industry  was  shown  where  TRW  efforts 
strongly  influenced  the  future  development  of  Valid  Logic  System's  CAE  software  tools. 
Valid  Logic  Systems  is  a  major  supplier  of  CAE  software  to  the  DoD  industry  base. 

The  work  performed  by  VPI  also  contributed  to  the  RAMCAD  goals.  The  need  to 
address  RM&S  in  the  curriculum  has  been  addressed.  Course  changes  have  been 
implemented  at  VPI.  That  school,  along  with  other  universities,  is  now  participating  in 
other  sponsored  efforts  to  implement  the  goals  identified  by  this  work. 

C .  THE  BOEING  CONTRACT 

Boeing  originally  proposed  performing  Tasks  I  and  II  but,  due  to  budget 
constraints  within  the  Air  Force,  they  were  awarded  a  modified  version  of  Task  II  only. 
One  of  the  main  factors  for  the  selection  of  Boeing  was  their  plan  to  look  at  how  artificial 
intelligence  (AI)  technology  could  be  used  in  addressing  the  engineers'  needs  in  a  future 
RAMCAD  system. 

The  contract  originally  awarded  to  Boeing  emphasized  the  development  of  software 
for  the  Air  Force  but  was  later  modified  to  allow  a  refocusing  of  the  effort  toward  research 
programs.  The  Boeing  work  began  many  months  after  the  other  contractors'  efforts,  and 
the  government  had  already  begun  to  receive  instructive  feedback  from  the  other  two 
contractors.  One  of  the  first  lessons  was  how  little  was  actually  known  about  the  design 
process  and  its  associated  testing.  It  was  realized  that,  without  some  preliminary  work  of 
the  type  outlined  in  Task  I,  progressing  with  the  standalone  Task  II  effort  would  be 
difficult  Boeing  and  the  government  decided  to  focus  initially  on  obtaining  a  clearer  view 
of  the  design  process,  to  enable  a  better  understanding  of  what  RAMCAD  could  contribute. 
Boeing  also  wanted  to  attempt  to  capture  the  senior  engineers'  experience  through  the  use 
of  Al-based/knowledge-based  interviewing  techniques. 

As  a  result  of  this  effort,  Boeing  has  documented  the  engineering  process  for  an 
electronic  designer,  at  Boeing,  in  one  of  the  best  descriptions  available  to  date.  They  are 
also  experimenting  with  AI  and  its  role  in  reliability  through  built-in  testability  (BIT) 
capability.  The  avionics  system  selected  for  the  initial  research  was  the  Ejector/  Stores 
Interface  Unit  (ESIU)  of  the  Bl-B  SRAM  II  Stores  Management  System  (SMS).  The 
ESIU  is  representative  of  the  type  of  avionics  designs  currently  found  in  the  aerospace 
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industry.  It  contains  a  mixture  of  off-the-shelf  and  custom-built  components  including 
microprocessors  and  has  a  comprehensive  BIT  capability.  At  the  time  of  selection,  the 
ESIU  was  an  active  design  project,  which  provided  access  to  designers  during  the  actual 
design  process  rather  than  during  a  re-creation  of  a  design  effort. 

In  conjunction  with  its  internal  RAMCAD  work,  Boeing  is  also  working  with 
Carnegie  Mellon  University  on  studying  the  design  process  with  the  goal  of  attaining  total 
automation  of  the  design.  Functional  specifications  for  small  computers  are  given  to 
Carnegie  Mellon’s  computer-based  design  system,  which  then  creates  a  complete  design 
for  a  small  computer  module  that  meets  the  performance  specifications.  The  output  of  then- 
system  is  a  schematic  with  recommended  part  values,  as  well  as  analysis  of  its  operational 
characteristics. 

The  Boeing  research  will  continue  for  approximately  12  months.  The  final  result  of 
this  effort  is  difficult  to  determine,  since  reports  are  not  due  until  contract  completion  in 
FY91. 

D .  THE  GENERAL  DYNAMICS  CONTRACT 

The  General  Dynamics  (GD)  contract  covered  Task  I  only;  however,  GD  was  to 
develop  a  prototype  RAMCAD  system  for  three  areas,  digital  or  analog  electronics, 
mechanical  design,  and  structural  design,  rather  than  for  only  one  area  as  the  PRDA 
required.  The  rationale  for  this  change  was  that  looking  at  three  disciplines,  their 
similarities,  differences,  and  interactions,  would  improve  understanding  of  what  actually 
occurs  in  the  design  process  and  thus  what  RAMCAD  prototypes  require. 

The  GD  work  was  separated  into  two  phases.  The  first  was  developing  a  working 
prototype  of  a  RAMCAD  system  with  a  limited  number  of  commercially  available  software 
programs  interacting  with  other  software  on  the  system.  This  prototype  will  serve  as  the 
basis  for  the  foundation  of  the  RAMCAD  system  software  to  be  developed  for  delivery  to 
the  program’s  sponsors  (Air  Force  and  Army).  Completion  of  the  prototype  will  meet  the 
conceptual  intent  of  the  original  PRDA.  The  second  phase  will  consist  of  further 
refinement  of  the  prototype  system  and  will  incorporate  some  of  the  work  as  outlined  in  the 
original  PRDA  Task  II. 

The  progress  to  date  under  this  contract  is  reported  in  detail  in  the  next  chapter. 
Copies  of  IDA's  monthly  comments  on  GD's  efforts  are  contained  in  Appendix  B. 
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m.  THE  GENERAL  DYNAMICS  PROGRAM 


This  chapter  summarizes  the  information  in  the  monthly  progress  reports  submitted 
by  General  Dynamics  (GD).  Detailed  IDA  comments  on  these  reports  are  contained  in 
Appendix  B.  The  course  of  the  GD  development  effort  was  approved  at  the  proposal  and 
award  stage  of  the  contract.  This  course  has  been  pursued  without  any  major  changes 
partly  because  the  contractual  restrictions  were  not  conducive  to  change. 

Following  a  kick-off  meeting  in  July  1987,  GD  began  its  efforts  by  investigating 
three  areas: 

•  The  design  process  (as  defined  by  GD's  own  engineers)  and  what  was 
involved— the  steps  and  drivers  associated  with  a  design.  This  investigation 
was  accomplished  through  interviews  with  engineers  from  GD's  Convair 
division. 

•  A  market  survey  of  all  currently  known  software  programs  for  use  with  a 
proposed  RAMCAD  system.  The  programs  had  to  be  commercially  available 
and  could  be  used  in  a  workstation  environment.  (Software  for  mainframes 
was  not  ignored,  but  GD's  plan  was  to  develop  a  RAMCAD  system  on  a 
workstation  and/or  microcomputer.)  The  survey  produced  some  interesting 
results.  In  electronic  design,  a  wide  selection  of  software  programs  were 
available,  but  the  options  for  mechanical  reliability  design  were  very  limited. 
The  electronics  industry  was  more  advanced  in  the  development  of  software- 
based  reliability  analysis  tools  than  were  their  mechanical  counterparts. 

•  A  RAMCAD  system  concept  that  took  into  account  the  results  from  the 
investigation  of  the  design  process  and  the  software  survey.  The  government 
wanted  to  see  the  results  of  a  RAMCAD  system  implemented  by  industry  as 
soon  as  possible.  GD  determined  that  the  most  expedient  approach  would  be 
to  use  software  already  developed,  integrate  the  different  packages  in  a  manner 
that  would  allow  them  to  exchange  information  directly  or  indirectly,  and  that 
was  consistent  with  the  process  already  in  place. 

During  the  first  year,  GD  gathered  details  to  learn  more  about  the  design  process. 
The  interviews  with  engineers  continued  until  they  felt  they  had  gathered  sufficient 
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information.  The  next  step  was  to  determine  how  to  present  all  of  the  information 
gathered.  From  this  research  it  became  evident  that  the  three  engineering  disciplines— 
mechanical,  structural,  and  electrical-used  significantly  different  approaches.  Each  had  its 
own  methodology  when  performing  design,  reliability  analysis,  and  support  analysis. 
These  differences  led  to  a  problem,  which  has  to  be  addressed,  determining  how  to  make 
design  trade-offs  among  the  different  disciplines. 

The  GD  system  concept  went  through  minor  changes  during  this  year.  The  primary 
driving  factors  for  these  changes  were  related  to  the  vendors  of  the  computer  equipment 
used  and  the  available  software.  The  primary  differences  among  the  vendors  were  related 
to  the  following  areas: 

•  The  viability  of  the  software  and  hardware  (i.e.,  was  the  product  available  and 
did  it  operate  as  advertised) 

•  The  cooperation  of  the  equipment  and  software  vendors  in  supplying 
information  on  how  the  products  functioned. 

GD  Concept  and  Prototype 

The  overall  GD  concept  is  described  as  follows.  First,  the  user  sees  and  uses  only 
one  system.  All  of  the  various  programs  used  in  the  RAMCAD  environment  are  linked  and 
presented  to  the  user  through  a  common  interface-even  if  the  programs  reside  and  are 
executed  on  other  computer  systems  connected  to  the  system  network.  The  RAMCAD 
Navigator  communicates  with  the  program  that  is  needed  for  analysis.  The  Navigator  starts 
the  program,  supplies  the  information  required  to  do  the  analysis,  stores  the  answer,  and 
presents  the  results  to  the  engineer  in  a  manner  consistent  with  his  request.  This  should 
allow  a  modular  approach  to  facilitate  the  addition  of  new  features  to  the  RAMCAD  system 
as  software  and  systems  progress. 

The  preliminary  RAMCAD  advanced  prototype  system  focused  on  electronics 
design  and  has  been  built  and  demonstrated.  The  current  prototype  work  now  under 
development  will  incorporate  mechanical  and  structural  as  well  as  electrical  design. 

Figure  III- 1  is  a  representation  of  the  architecture  of  this  system.  The  RAMCAD 
system  software  was  developed  in  both  languages  of  C  and  Oracle  (an  SQL-based  data 
base)  to  help  ensure  that  minimal  effort  would  be  necessary  to  move  the  system  to  a  new 
platform;  the  government  considers  transportability  an  important  issue. 
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FUNCTIONS  OF  THE  RAMCAO  NAVIGATOR 


Whan  tha  uaar  raquaMa  ana^iia  via  Via  uaar  Intartaca: 

1.  Tha  uaar  imartaea  caJta  tor  lha  anaemia  apptioaOon  program  axacubon  oommanda  from  Via  Nadgnor  and- 

2.  Estabdahaa  nshsorfc  communionions  with  tha  apoScaaion  program  host  Tha  applcadon  program  may  batocMad  an  lha  aar.a  oomputar  as  Via  uaaf 
intartaca  or  on  a  ramotaiy  locasd  oomputar. 

3.  Tha  Naaigstor  tala  tha  D6MS  to  aand  tha  raquirsddaa to  lha  Appleadon  Pro»ani  Input  Form*  Tabla. 

9  4.  Tha  d 0m  a  fotmattad  tor  Input  to  tha  a^dicadon  program. 

5.  Tha  tormadtad  Input  ISs  and  appdcadon  program  atart*up  tnarructiona  ara  paaaad  to  Via  appioaion  program  lor  oomputnion. 

6.  Tha  appfloaaion  program  parforma  tha  analysis  function  and  aanda  tha  ou|>ul  Into  Via  Applcodon  Programs  Output  sacdon  ol  tha  Nswigsaor. 

7.  Whan  tha  dna  transtar  is  oompista,  tha  Navigator  aanda  tha  d«a  to  tha  OtRou  TranaMor.  Tha  TransMer  aanda  data  to. . . 

8.  Tha  Main  ONahaaa  »tatha  Navigator's  Oaaabaaa  Input  Forman  Sacdon  and. . . 

9.  Tha  Uaar  Intartaca  for  tha  angjnaafs  analysis. 


Figure  IIM.  GD  System  Concept 
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IV.  CONCLUSIONS 


A.  THE  CHANGING  RAMCAD  ENVIRONMENT 

In  the  five  years  that  have  elapsed  since  the  formation  of  the  first  tri-Service 
RAMCAD  group,  the  entire  CAE  environment  has  changed  radically.  Vendor  and 
contractor  activities  relevant  to  RAMCAD  issues  have  increased  substantially.  If  the  PRDA 
tasks  were  to  be  rewritten  today,  far  more  ambitious  goals  than  were  initially  set  would  be 
pursued.  This  is  due  to  the  rapidly  advancing  computer  environment  of  computer  systems 
and  new  computer  program  development  tools,  particularly  for  the  prototype  development 
of  Task  I.  This  rate  of  change  was  partially  recognized  and  led  to  the  incorporation  of 
some  of  the  research  elements  of  Task  II  into  the  General  Dynamics  contract. 
Nevertheless,  the  impact  of  the  prototype  on  the  outside  world  will  be  less  when  it  is  finally 
completed  than  would  have  been  the  case  if  it  had  been  completed  earlier.  Had  the  start  of 
the  program  been  on  the  time  schedule  originally  planned  and  the  funding  level  been  as 
planned,  RAMCAD  would  be  finished  a  year  earlier.  More  contractors  would  have  been 
influenced  by  RAMCAD  innovations  and  be  further  along  today  in  its  use. 

During  this  time  a  major  change  in  the  DoD  environment  in  relation  to  weapon 
systems  design  has  also  occurred.  As  noted  previously,  the  CALS  initiative  has  gained 
great  momentum  and  in  the  process  has  expanded  to  full-fledged  support  of  the  goals  of  the 
concurrent  engineering  initiative.  The  goals  of  RAMCAD  and  concurrent  engineering,  in 
terms  of  producing  a  better  product,  are  identical.  Both  call  for  the  same  type  of  changes  in 
the  design  process  to  accomplish  this  goal.  RAMCAD  is  thus  considered  a  major  element 
of  concurrent  engineering  by  the  CALS  community. 

Today,  a  closely  related  recent  OSD  initiative  is  Total  Quality  Management  (TQM), 
which  has  the  goal  of  continuously  improving  the  quality  of  the  work  output  of  every 


element  of  an  organization,  both  staff  and  line.5  Concurrent  engineering  in  most  industrial 
concerns  is  treated  as  the  engineering  element  of  the  company's  TQM  program.  Much  of 
the  growing  industry  interest  in  RAMCAD  can  be  attributed  to  the  fact  that  it  is  considered  a 
major  element  contributing  to  the  larger  concurrent  engineering  and  total  quality 
management  programs. 

B .  FUTURE  PROSPECTS  FOR  THE  GENERAL  DYNAMICS  PROGRAM 

IDA  noted  at  the  Preliminary  Design  Review  (PDR)  (Appendix  B,  p.  B-19)  that  GD 
is  developing  a  workstation  and  network  that  allow  a  more  rapid  R&M  evaluation  of  a 
design.  To  what  extent  these  elements  will  be  turned  into  a  design  tool— become  an  integral 
part  of  the  design  trade-off  process— remains  to  be  seen.  GD's  Integrated  Manufacturing 
System  (IMS)  project  includes  RAMCAD  as  part  of  the  company-funded  development 
program  at  Convair,  which  indicates  that  the  workstation  and  network  are  becoming  part  of 
the  trade-off  process.  RAMCAD  as  it  exists  today  has  already  influenced  how  GD  does 
business.  It  was  used  on  the  advanced  cruise  missile  program  to  validate  work  done  by  a 
subcontractor  to  ensure  compliance  with  the  design  specifications  for  their  task.  RAMCAD 
was  also  used  in  the  conceptual  design  phase  of  a  new  missile  for  the  year  2000.  GD  has 
invoked  an  internal  policy  requiring  that  a  baseline  system  (existing  design)  be  compared 
against  any  new  concept  for  improvement  GD  has  reported  that  the  current  advanced 
prototype  RAMCAD  was  used  successfully  to  test  the  effect;  of  new  technologies  on  an 
existing  design. 

One  of  the  useful  results  of  the  GD  program  is  a  practical  evaluation  of  the 
similarities  and  differences  between  RAMCAD  analyses  for  mechanical,  structural,  and 
electronic  systems.  An  issue  remaining  to  be  addressed  is  the  integrated  use  of  these  tools 
on  one  design.  While  the  tools  could  be  used  individually  to  evaluate  a  design  once  it  is 
complete,  the  problem  of  when  and  how  to  use  them  interactively  during  the  design  to 
effect  more  optimal  R&M  results  requires  further  investigation. 

Another  potentially  useful  result  of  the  GD  program  is  in  addressing  the  problem  of 
analyzing  mechanical  reliability  statistically  as  is  routinely  done  for  electronic  systems. 


5  The  impact  and  importance  of  TQM  are  reflected  in  a  memo  from  then  Under  Secretary  of  Defense  for 
Acquisition,  Robert  Costello,  which  calls  for  implementation  of  TQM.  The  memo  is  contained  in 
Appendix  D.. 
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Though  experimental  approaches  exist,  there  is  a  fundamental  question  as  to  how  useful 
this  type  of  analysis  may  be.  Addressing  this  question  would  be  a  very  useful  result. 

C .  POTENTIAL  AVENUES  OF  IMPROVEMENT 

1 .  How  does  one  do  a  trade-ojf  among  different  design  disciplines? 

The  GD  RAMCAD  system  addresses  three  major  engineering  disciplines—electrical, 
structural,  and  mechanical.  Each  was  being  addressed  individually.  The  system  designer 
will  have  to  determine  the  optimum  trade-offs  to  be  made  among  these  three  disciplines 
which  each  discipline  is  competing  for  the  same  design  space.  A  method  for  assisting  the 
designers  in  performing  such  trade-offs  is  needed.  A  major  issue  is  determining  whether 
these  trade-offs  are  necessarily  subjective  or  whether  they  can  be  made  quantitative. 

2 .  Research  the  need  for  and  development  of  a  consistent  user  interface  among  the 
different  software  packages  integrated  in  a  RAMCAD  system. 

The  commercial  computer  market  has  demonstrated  the  benefits  to  be  gained  in  time 
and  training  cost  of  a  common  method  for  operating  different  computer  programs.  It  is  this 
common  mode  of  operating  a  computer  system  that  has  led  to  the  rapid  development  and 
growth  of  the  "user  interface."  Both  Microsoft  Corporation  and  Apple  Computer  are 
attempting  to  develop  a  standard  graphics-based  representation  of  the  computer  operation. 
They  are  the  two  largest  suppliers  of  computer  operating  systems  in  the  world. 

The  current  RAMCAD  advanced  prototype  is  just  beginning  to  address  how  to  best 
present  the  user  with  the  requested  information  and  the  possibility  of  having  all  similar 
functions  from  the  different  analyses  programs  operated  in  the  same  manner.  An  example 
of  this  would  be  in  printing  a  report  when  the  analysis  is  completed  by  a  program.  If  the 
interface  to  the  user  is  the  same  for  all  programs  when  the  user  wishes  to  print,  then  they 
know  how  to  do  it  for  all  the  other  programs. 

If  we  apply  this  knowledge  gained  in  the  development  of  the  user  interface  to 
RAMCAD,  we  can  increase  the  acceptance  and  use  by  the  design  community. 

3 .  Is  RAMCAD  a  tool  for  a  single  designer  or  for  assisting  a  design  team  that  represents 
the  different  disciplines  associated  with  the  product  definition? 

The  current  RAMCAD  system,  as  demonstrated  by  GD,  is  designed  to  interact  with 
one  user.  With  the  advent  of  TQM,  which  emphasizes  a  team  approach,  the  system  may 
need  to  be  expanded  in  a  manner  that  will  facilitate  a  team  of  designers  working 


interactively  through  a  network  while  developing  a  new  design.  The  system  should  also  be 
modified  to  address  the  team's  need  to  work  face  to  face,  such  as  during  a  design  review 
meeting. 

4 .  Data  Availability  in  Computer-Readable  Formats. 

Technical  data  should  be  available  for  electronic  components  in  a  computer-readable 
format.  Most  of  the  technical  data  available  today  on  electronic  components  is  in  printed 
form,  which  requires  that  this  data  be  read  by  an  operator,  entered  into  the  system,  and 
formatted  for  the  CAD  or  CAE  data  base  system  of  choice.  To  add  to  this  problem,  the 
format  of  the  information  stored  on  different  systems  varies  with  the  developer  of  the  CAD 
or  CAE  program  being  used.  Standardization  among  the  different  CAD  or  CAE  data  bases 
would  allow  electronic  transfer  of  information.  The  component  manufacturers  could 
produce  the  necessary  data  in  an  electronic  form  for  less  than  it  cost  them  to  print  it  and 
allow  for  updates  or  additions  to  their  information  to  be  available  in  a  matter  of  days,  not 
months. 

5 .  Computer  tools  ( Software )  Address  the  Mechanical  and  Supportability  Disciplines 

The  RAMCAD  program  software  survey  revealed  that  the  existing  software  is 
geared  to  the  electronics  industry.  Software  for  non-electronic  environments  has  probably 
not  been  developed  because  the  methodologies  for  these  areas  do  not  lend  themselves  to  an 
automation  process.  Thus,  current  CAE  and  CAD  software  was  developed  to  address 
specific  needs  of  the  workstations  for  electronic  designers.  Further  investigation  is 
necessary  to  determine  what  tools  are  needed  for  the  non-electronic  environment  and  how 
this  environment  can  be  represented  in  an  electronic  model. 

6 .  Quality  Control  in  Software  Tools 

In  GD  research  of  software  tools  they  discovered  that  some  software  reported  to 
represent  the  Military  Standard  217  Handbook  produced  errors.  The  results  generated  by 
the  program  were  shown  to  be  incorrect  based  on  a  manual  check  of  the  same  calculations. 

Software  tools,  while  being  developed,  must  be  checked  and  rechecked  for 
consistency  and  the  accuracy  of  their  output;  otherwise  the  design  community  will  not  use 
them. 
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7.  Management  Acceptance  of  and  Support  for  RAMCAD 

Until  management  acknowledges  that  RAMCAD  can  be  used  to  deliver  both  a  near- 
term  and  long-term  cost  benefit,  it  may  be  discussed  but  will  not  be  used  in  the  design 
process.  If  management  does  not  recognize  the  need  to  emphasize  the  use  of  RAMCAD, 
its  use  may  be  limited  to  creating  electronic  data  for  CALS. 

D.  TRANSITION  PLAN  FOR  PICATINNY  ARSENAL 

Having  reviewed  the  history,  development,  and  current  status,  we  must  now 
address  the  question,  "What  should  be  the  next  step  for  the  RAMCAD  program?"  We  need 
to  move  RAMCAD  from  the  lab  into  an  actual  DoD  environment  to  properly  determine  its 
usefulness  and  next  direction  for  development.  Since  the  US  Army  Armament  Research, 
Development,  and  Engineering  Center  (ARDEC)  at  Picatinny  Arsenal  is  the  main  sponsor 
of  the  General  Dynamics  RAMCAD  program  and  since  ARDEC  works  on  weapons  design 
from  concept  through  first  production,  this  would  be  an  excellent  environment  for 
RAMCAD.  It  is  essential  that  a  proper  implementation  plan  be  researched  and  developed. 
Issues  such  as  computer  system  and  other  compatibilities  within  the  existing  engineering 
process  at  Picatinny  must  be  considered.  Engineering  is  particularly  important  because  of 
the  many  changes  that  are  required  to  introduce  RAMCAD  and  eventually  TQM  techniques. 

Another  issue  for  implementation  will  focus  on  the  reliability  analyses  that  would  be 
acceptable  to  the  Picatinny  design  community,  particularly  in  mechanical  design.  The 
software  selections  made  by  GD  are  rational  for  a  demonstration  but,  as  noted  in  the  PDR 
comments  (Appendix  B),  what  the  mechanical  engineering  design  community  will  accept  or 
need  is  still  to  be  determined. 

An  approach  to  development  of  a  plan  on  how  to  best  introduce  RAMCAD  at 
Picatinny  Arsenal  is  contained  in  Appendix  E.  This  document  discusses  the  process  for 
developing  such  a  plan. 
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Appendix  A 


THE  PROGRAM  RESEARCH  AND 
DEVELOPMENT  ANNOUNCEMENT1 


A.  RAMCAD  SOFTWARE  DEVELOPMENT  (ADVANCED 
DEVELOPMENT),  PRDA  #86-16-MRS 

This  is  a  Program  Research  and  Development  Announcement  (PRDA).  The  Air 
Force  Human  Resources  Laboratory  (AFHRL/LR)  is  interested  in  receiving  proposals 
(technical  and  cost)  on  the  research  effort  described  below.  It  is  desired  that  proposals  in 
response  to  this  PRDA  be  submitted  by  1530  hours,  17  June  1986,2  addressed  to:  HQ 
Aeronautical  Systems  Division,  Building  7,  Area  B,  Attention:  ASD/PMRSC,  Wright- 
Patterson  AFB,  OH  45433-6503.  Proposals  submitted  must  be  in  accordance  with  this 
announcement.  There  will  be  no  formal  request  for  proposal  or  other  solicitation  request  in 
regards  to  this  requirement.  Proposals  submitted  should  be  in  general  accordance  with  the 
AFSC  Guide  for  Program  Research  and  Development  Announcement  (AFSCP  70-4,  dated 
25  April  1984).  A  copy  of  this  guide  is  available  upon  request  from  ASD/PMR-1, 
WPAFB,  OH  45433-6503,  (513)  255-3825,  Offerors  should  be  alert  for  any  PRDA 
amendments  that  may  be  published.  The  selection  of  one  or  more  sources  for  contract 
award  will  be  based  on  a  scientific  and  engineering  evaluation  of  the  proposals  received 
(technical  and  cost)  to  determine  the  relative  merit  of  the  approach  taken  in  response  to  this 
announcement.  New  and  creative  solutions  are  of  primary  interest  and  will  be  ranked  first 
in  the  evaluation  process.  Cost  is  ranked  second.  No  other  evaluation  criteria  will  be  used 
in  the  source  selection.  Proposals  must  provide  new  or  unique  concepts,  ideas,  or 
approaches  to  be  considered  for  award.  Responses  should  reference  the  above  PRDA 
number.  The  Air  Force  reserves  the  right  to  select  for  award,  all,  part,  or  none  of  the 
proposals  received.  The  cost  of  proposal  preparation  in  response  to  this  announcement  is 
not  to  be  considered  an  allowable  direct  charge  to  any  resulting  contract  or  to  any  other 


1  Synopsis  in  Commerce  Business  Daily  (R&D  Sources  Sought);  published  15  May  1986. 

2  Extended  to  27  June  1986. 
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contract  It  is,  however,  an  allowable  expense  to  the  normal  bid  and  proposal  indirect  cost 
as  specified  in  FAR  31.205-18.  Proposals  must  be  submitted  in  an  original  plus  three 
copies.  The  Air  Force  Human  Resources  Laboratory  has  initiated  several  efforts  to 
integrate  Reliability  and  Maintainability  into  Computer-Aided  Design  (RAMCAD).  It  is  the 
intention  of  the  Laboratory  to  establish  a  cooperative  effort  consisting  of  universities  and 
industry  members  to  conduct  research  and  development  in  the  area  of  RAMCAD.  This 
effort  is  directed  at  supporting  the  establishment  of  the  RAMCAD  cooperative  effort  As  a 
result  the  purposes  of  this  effort  are: 

( 1 )  The  development  of  a  prototype  RAMCAB^ystem 

(2)  The  accomplishment  of  fundamental  research  in  this  area 

(3)  The  development  of  an  engineering  curriculum  incorporating  RAMCAD. 

It  is  anticipated  that  offerors  would  respond  to  one  or  more  but  not  all  of  the  tasks. 
The  technical  proposal  must  include  an  outline  and  full  discussion  of  the  nature  and  scope 
of  the  research,  the  method  or  technical  approach,  and  the  expected  results. 

B.  (1)  REQUIREMENTS 

Task  1.  Prototype  RAMCAD  System 

The  objective  of  Task  1  is  to  develop  application  software  and/or  a  translating 
device  capable  of  integrating  stand-alone  commercially  available  reliability,  maintainability, 
and  supportability  (RM&S)  software  with  Computer-Aided  Design  software.  Task  1  at  a 
minimum  consists  of  the  following  subtasks: 

(a)  Simulate  the  design  process  for  an  aerospace-related  defense  equipment  within 
one  of  the  following  areas. 

(i)  Digital  or  analog  electronics 

(ii)  Mechanical  design 

(iii)  Structural  design. 

The  complexity  of  this  equipment  design,  whether  electronic,  mechanical,  or 
structural,  shall  be  roughly  equivalent  to  that  of  an  electronic  device  with  a 
minimum  of  25  components  representing  at  least  4  component  types. 

(b)  Identify  and  document  the  information  requirements  to  accomplish  reliability, 
maintainability,  and  supportability  analyses  consistent  with  the  appropriate 
Military  Specifications  and  Standards  for  the  design  selected  in  Subtask  la. 
This  shall  include  the  identification  of  major  competing  design  attributes  for 
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performance,  reliability,  maintainability,  supportability,  cost,  and  schedule  for 
the  design  selected  in  Subtask  la. 

(c)  Identify,  classify,  and  document  all  commercially  available  software  to 
accomplish  reliability,  maintainability,  and  supportability  analyses  to  meet  the 
requirements  identified  in  Subtask  lb.  This  classification  shall  include  the 
computer(s)  on  which  the  software  runs,  the  phase  of  design  in  which  it  is 
used,  and  the  function  of  the  analysis  within  the  design.  The  classification 
shall  also  include  the  softwares’  input  and  output  requirements,  data  formats, 
modeling  capacity  (i.e.,  the  size  of  the  problem  on  which  it  is  typically  used), 
and  any  other  known  limitations  or  requirements. 

(d)  Develop  and  document  a  conceptual  schema  for  integrating  a  minimum  of  three 
diversely  different  RM&S  softwares  together  with  a  CAE  system. 

(e)  From  experience  and  interviews  with  a  representative  cross  section  of  design 
engineers,  develop  and  document  the  man-machine  interface  requirements 
(i.e.,  user  friendliness)  necessary  to  ensure  acceptance  by  the  design  engineers 
of  the  integrated  system  to  be  developed  in  Subtask  If. 

(f)  Prepare  a  plan  for  developing  the  application  software  and/or  translating  device 
capable  of  integrating  three  or  more  diversely  different  analyses  together  with  a 
widely  used,  commercially  available  CAD  station  and  demonstrate  the 
integration  on  a  Government-approved  computer  system.  The  plan  shall 
specify  the  approach,  intermediate  products  for  review,  the  required  inputs, 
and  the  expected  results  as  well  as  the  conditions  of  the  final  demonstration. 
The  plan  shall  also  include  formal  provisions  for  regular  interaction  with  the 
developer(s)  of  Tasks  2  and  3. 

(g)  With  Government  approval  of  the  plan  in  Subtask  If,  the  necessary 
software/translating  device  for  implementing  the  plan  shall  be  developed. 

(h)  Prepare  and  deliver  the  software/translation  device  and  a  users'  manual  for 
utilizing  the  application  software  and/or  translation  device.  The  software/ 
translator  and  manual  shall  be  of  sufficient  detail  to  permit  their  application  in 
the  design  of  a  typical  device  as  chosen  in  Subtask  la. 

Task  2.  Fundamental  R&D 

The  objective  of  Task  2  is  to  conduct  long-term  research  in  the  following  areas: 

•  The  improvement  of  the  computer-assisting  techniques  associated  with 
reliability,  maintainability,  and  supportability  analysis. 

•  The  development  of  methodologies  to  evaluate  and  validate  the  techniques 
developed  under  this  task  as  well  as  those  employed  in  Task  1.  Task  2  at  a 
minimum  consists  of  the  following  subtasks: 
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(a)  Select  one  area  of  research  from  electronics,  mechanical,  or  structural 
engineering  disciplines. 

(b)  Define  a  proposed  methodology  to  assist  the  engineer  in  optimizing 
among  competing  design  requirements  (i.e.,  performance,  reliability, 
maintainability,  supportability,  cost,  and  schedule).  All  levels  of 
assembly  from  the  lowest  subassembly  level  to  the  entire  weapon  system 
shall  be  addressed. 

(c)  Identify  those  areas  of  design  analysis  technologies  within  the  RM&S 
disciplines  which  require  improvement  or  new  developments  to 
accomplish  Subtask  2b. 

(d)  Define  proposed  evaluation/validation  techniques  (benchmarks)  for  the 
techniques  identified/developed  in  Subtask  2b. 

(e)  Develop  a  research  plan  detailing  potential  solutions  to  a  subset  of  the 
problems  identified  in  Subtasks  2b-d,  and  a  method  for  achieving  them 
within  the  scope  of  the  anticipated  funding.  The  plan  shall  also  include 
formal  provisions  for  regular  interactions  with  the  developer(s)  of  Tasks  1 
and  3. 

(f)  Upon  Government  approval  of  the  plan,  develop  the  prototype  techniques 
identified  in  the  plan. 

Task  3.  RAMCAD  Engineering  Curricula 

The  objective  of  Task  3  is  to  develop  engineering  curricula  that  address  the  use  of 
RAMCAD  in  a  computer-aided  design  process.  Task  3  as  a  minimum  consists  of  the 
following  subtasks. 

(a)  Establish  a  series  of  workshops  with  a  representative  cross  section  of 
engineering  universities  and  the  developer(s)  of  Tasks  1  and  2  to  obtain  and 
document  suggestions  for  the  curricula  development  and  implementation. 

(b)  Prepare  a  plan  for  the  development  of  the  curricula  to  address  all  of  the  design 
disciplines  of  electronic,  mechanical,  and  structural  design. 

(c)  Upon  ratification  by  the  university  workshop  members  of  Subtask  3a,  and 
approval  by  the  Government,  prepare  prototype  curricula.  The  technical 
proposal  must  include  an  outline  and  full  discussion  of  the  nature  and  scope 
of  the  research,  the  method  or  technical  approach,  and  the  expected  results. 
Also  include  a  description  of  available  facilities  and  resumes  of  personnel  who 
will  be  participating  in  the  effort.  The  accompanying  cost  proposal/price 
breakdown  should  be  supplied  on  SF141 1,  together  with  supporting  detailed 
cost  schedule.  Proposals  must  reference  the  above  number. 
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(2)  DELIVERABLE  ITEMS 

The  following  deliverable  items  are  required:  The  contractor  shall  deliver: 

(a)  R&D  Status  Report,  DI-A-3002  (monthly) 

(b)  Performance  and  Cost  Report,  DI-F-1208A  (monthly) 

(d)  Cost/Schedule  Status  Report,  DI-F-6010A  (quarterly) 

(e)  Contract  Work  Breakdown  Structure,  DI-A-3023 

(f)  Detailed  Research  Plan,  DI-S-30595 

(g)  Interim  Report  on  Research  and  Development,  DI-A-5023  (as  required) 

(h)  Final  Technical  Report,  DI-S-3591A  (draft  and  reproducible  final) 

(i)  Computer  Software  Product,  DI-H-5545  (as  required) 

(j)  Computer  Software/Computer  Program  Data  Base  Configuration  Item(s), 
DI-E-30145  (as  required) 

(k)  Abstract  of  New  Technology,  DI-A-3028B. 

(3)  TOTAL  CONTRACT  PERIOD  ANTICIPATED 

45  months  of  technical  effort  plus  four  months  to  process  the  final  report. 

(4)  EXPECTED  AWARD  DATE 
Between  1  June  1986  and  1  September  1986 

(5)  GOVERNMENT  ESTIMATE 
Minimum  of  42.5  man  years  of  effort 

(6)  TYPE  OF  CONTRACT 

Cost  Plus  Fixed  Fee  with  a  maximum  cost  of  $3M 

(7)  GOVERNMENT  FURNISHED  PROPERTY 
None 

(8)  SECURITY  REQUIREMENTS 

It  is  anticipated  that  all  work  performed  under  this  contract  will  be  unclassified 

(9)  SIZE  STATUS:  See  Note  No.  11. 

Firms  responding  should  indicate  whether  they  are  Small  Business  or  a  Certified 
8(a)  Business 


(10)  NOTICE  TO  FOREIGN  AND  FOREIGN-OWNED  FIRMS 

Such  firms  are  asked  to  immediately  notify  the  Air  Force  contact  point  cited  below 
upon  making  a  decision  to  respond  to  this  announcement  This  action  is  necessary 
to  begin  review  and  clearance  procedures.  Such  firms  may  elect  to  await  the 
determination  before  incurring  costs  in  proposal  preparation 

(11)  PRDA  CONTACT  POINTS 

Questions  on  technical  issues  may  be  referred  to  the  project  engineer,  Air  Force 
Human  Resources  Laboratory,  Logistics  and  Human  Factors  Division, 
AFHRL/LRA,  Attention:  Capt.  Lois  Gutter,  Wright-Patterson  AFB,  OH  45433- 
6503,  (513)  255-3871.  Questions  on  contractual/cost  issues  should  be  directed  to: 
Directorate  of  R&D  Contracting,  ASD/PMRSC,  Attention:  John  M.  Lipker, 
Wright-Patterson  AFB,  OH  45433-6503,  (513)  255-5633.  All  questions  must  be 
submitted  in  writing  within  12  days  of  date  of  publication  of  this  announcement. 
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INSTITUTE  FOR  DEFENSE  ANALYSES  COMMENTS  ON 
GENERAL  DYNAMICS  MONTHLY  REPORTS 

(UNEDITED) 


The  following  are  review  comments  made  by  IDA  and  provide  a  history  of  the 
progress  and  a  picture  of  the  current  status  of  the  GD  program. 

A.  JULY  1987  TO  AUGUST  1989 

1 .  July  6  to  September  30,  1987  -  Initial  Efforts 

A  kick-off  meeting  was  held  in  San  Diego  on  July  6, 1987.  The  General  Dynamics 
(GD)  team  is  focusing  on  three  key  areas: 

(1)  The  Design  Process  as  seen  from  a  Convair  perspective.  Their  first  task  will 
be  attempting  to  determine  how  the  Convair  process  works.  One  of  the  models 
is  a  business  model  prepared  by  their  Integrated  Resource  Management  (IRM) 
group.  Fortunately,  they  are  establishing  contacts  within  the  engineering 
groups  to  try  to  get  the  designers'  perspective. 

(2)  A  Software  Survey  of  potential  suppliers  of  programs  that  might  be  used  in  the 
RAMCAD  prototype. 

(3)  The  RAMCAD  System  Concept.  This  is  a  misnomer  as  they  are  really 
focusing  on  the  hardware;  and  any  real  system  considerations  will  have  to 
include  the  software  survey  results.  They  should  recognize  that  the  software, 
not  the  computer  experts,  will  define  the  hardware  platform. 

The  GD  RAMCAD  contract  was  finally  signed  on  September  14  so  the  above  work 
was  really  preliminary  in  nature. 
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2 .  October  1987  -  Monthly  Status  Report 


The  October  1987  monthly  status  report  reviews  the  three  areas  described  above: 

(1)  Design  Process  Simulation 

An  ambitious  survey  form  has  been  completed  that  covers  three  primary  areas: 
what  is  the  design  philosophy  at  Convair,  how  does  an  engineer  determine 
trade-offs,  and  where  in  the  design  process  is  consideration  given  to  RM&S 
issues.  We  may  find  that  this  effort  is  attempting  to  acquire  too  much 
information  at  one  time.  The  same  group  that  will  receive  the  survey  was 
involved  in  a  study  done  last  year.  A  review  should  be  made  of  how  the 
information  gained  last  year  turned  out  after  a  year  of  reflection. 

GD  plans  to  review  these  new  survey  responses  with  the  knowledge  gained 
from  their  study  of  other  "classical"  design  processes.  However,  it  is  not  clear 
how  this  study  will  be  used  to  check  the  survey  results.  What  are  the  criteria 
for  comparison? 

(2)  RM&S  Software  Survey 

A  multilevel  screening  process  of  vendors  is  under  way.  This  should  reduce 
some  of  the  review  time.  It  would  be  interesting  to  see  and  understand  how 
their  "checklist"  was  developed. 

(3)  RAMCAD  Syslgm.£ancgEt 

A  second  kickoff  meeting  (now  that  the  contract  was  signed)  was  held  in  San  Diego 
with  only  the  Air  Force,  Army,  and  GD  in  attendance.  The  monthly  report  reflected  the 
key  issues  that  arose: 

What  should  the  hardware  be  for  RAMCAD?  It  now  appears  that  the  hardware 
equipment  selections  will  be  largely  determined  by  what  systems  are  to  receive 
the  product  at  Wright-Patterson  Air  Force  Base  and  at  Picatinny.  The  software 
may  thus  have  a  secondary  influence.  This  is  all  right  for  a  prototype  system 
but  what  about  the  next  iteration  of  the  RAMCAD  system?  Shouldn't  we  look 
at  the  future  implications  of  the  current  decisions? 

We  concur  with  their  strong  support  for  Unix  and  X-windows.  Both  of  these 
will  be  in  use  by  the  majority  of  systems  in  the  government  in  the  near  future. 
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3.  November  1987  Status  Report 

(1)  Design  Process  Simulation 

Is  progressing  with  the  added  benefit  of  interviews  with  engineers. 

(2)  Software  Survey 
No  comments. 

(3)  RAMCAD  System  Concept 

Work  is  progressing  in  the  technical  considerations  for  a  prototype  system. 
There  needs  to  be  more  thought  as  to  its  purpose  and  the  human  interface.  The 
survey  will  help  both  of  these  areas.  However,  it  appears  the  results  of  the 
survey  will  be  finished  at  the  same  time  as  the  advanced  prototype  system 
design.  The  system  design  needs  the  results  of  the  software  survey  and  the 
engineers'  inputs  to  become  a  true  RAMCAD  system. 

4.  November  17  Trip  to  General  Dynamics,  San  Diego 

Watts  Hill  attended  the  last  half  of  the  GD  RAMCAD  staff  meeting.  He  discussed 
the  RAMCAD  concept  and  its  history  that  brought  us  to  the  PRDA  announcement.  This 
was  helpful  to  the  GD  team  as  most  were  new  to  RAMCAD  and  not  part  of  the  technical 
proposal  team.  There  has  been  a  lot  of  progress  in  the  two  years  since  the  PRDA  was 
conceived. 

Watts  then  worked  with  Hal  Pal  on  methods  to  develop  a  microplanner  schedule  for 
the  GD  program.  Unfortunately,  the  key  goal  of  this  effort  is  not  being  done  correctly, 
because  all  participants  must  have  input  into  the  development  of  a  schedule  and  the 
dependencies  associated  with  their  tasks.  Hal  is  attempting  to  develop  a  schedule  based  on 
his  personal  experience  and  the  contract  milestones.  This  will  give  us  a  graphical  picture  of 
the  GD  program  and  the  tasks  and  their  dependencies.  Unfortunately,  it  will  not  be  truly 
representative  of  the  actual  GD  program. 


5 .  December  1987  Status  Report 


(1)  Design  Process  Simulation 

Two  key  points  are  brought  out  in  this  month’s  report: 

1 .  The  problem  of  how  to  represent  the  information  gathered  in  their  survey 
and  interviews  with  engineers. 

2.  The  need  to  diagram  Convair's  Individual  Design  groups  and  their 
interactions. 

Point  1  is  an  understandable  problem  given  the  size  and  scope  of  the  three 
areas  they  were  attempting  to  address  in  one  survey.  Hindsight  would  suggest 
that  more  work  and  thought  applied  to  the  creation  of  the  questionnaire,  and 
into  how  to  use  the  information,  would  have  reduced  the  size  of  this  problem 
to  a  manageable  level. 

(2)  RM&S  Software  Survey 

Again,  we  see  the  concern  with  the  volume  of  data  collected  and  how  best  to 
represent  it.  This  problem,  while  it  is  not  trivial,  would  be  more  easily  dealt 
with  if  the  data  needs  and  their  use  were  defined  before  the  survey  was 
developed.  Perhaps  they  are  finding  it  difficult  due  to  a  lack  of  knowledge  of 
what  they  want  out  of  the  data.  GD  states  that  Repair  Level  Analysis  (RLA) 
and  Electronics  Reliability,  Availability,  and  Maintainability  Simulation 
(ERAMS)  are  both  in  the  public  domain  now  but  we  are  not  aware  that  this  is 
the  case.  Suggest  they  check  this  again. 

(3)  RAMCAELSystem  Concept 

Again,  there  is  concern  over  designing  the  prototype  before  analyses  of  the 
engineers'  design  process  and  the  software  survey  are  completed.  The  process 
should  be  to  determine  the  users'  needs,  find  the  software  programs  to  meet 
these  needs,  and  then  determine  the  hardware  to  meet  the  software  needs. 

The  consideration  of  using  Oracle  or  Informix  as  the  data  base  shows  some 
good  forethought.  Both  data  bases  are  based  on  the  SQL  language,  which 
allows  for  the  substitution  of  either  one  and  is  clearly,  in  the  near  future,  the 
best  data  base  query  language  for  most  systems,  large  or  small.  As  to  the 
question,  is  it  the  way  for  RAMCAD  to  go,  we  don’t  know  enough  about 
RAMCAD  needs  to  decide  that  now. 

This  month's  report  also  shows  that  they  are  getting  more  specific  with  respect 
to  the  modules  they  want  to  incorporate  in  their  prototype.  Looking  at  different 
software  modules  can  be  productive  at  this  point  in  order  to  begin  to  identify 
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what  sort  of  interfacing  requirements  may  have  to  be  addressed  once  the  final 
decision  is  made  on  the  specific  modules. 

6 .  January  1988  -  Status  Report 

(1)  Design  Process  Simulation 

The  issue  of  combining  mechanical,  electrical,  and  structural  sections  in  their 
design  process  is  not  being  addressed:  one  should  note  that  they  are  currently 
only  addressing  the  question  of  combining,  not  the  key  issue  of  integration. 
Perhaps  the  most  important  aspect  to  this  work  is  the  identification  of  the 
different  "ilities"  that  each  discipline  addresses  and  the  lack  of  commonalty 
among  them.  Since  the  mechanical  and  structural  disciplines  traditionally 
design  to  "safety  factor"  and  "infinite"  life  for  a  given  stress  criteria,  instead  of 
reliability  per  se,  the  need  to  look  beyond  the  advertised  Reliability, 
Maintainability,  and  Supportability  (RM&S)  software  field  has  arisen.  This 
problem  will  have  to  be  studied  and  dealt  with  in  any  RAMCAD  development 
which  deals  with  more  than  just  electrical  design,  as  does  GD's. 

(2)  Software  Survey 

Software  Survey  Selection  Form.  This  form  needs  a  great  deal  of  explanation 
concerning  the  actual  questions  being  addressed  and  their  purpose. 

The  rating  system  is  unknown.  How  are  they  scoring  these  questions  and  how 
is  each  weighed? 

(3)  RAMCAD  System  Concept 

Informix  has  been  picked  as  the  data  base  for  the  prototype  RAMCAD.  At  the 
SDR  it  will  be  interesting  to  hear  why  Informix  was  chosen  over  Oracle.  Both 
have  excellent  reputations.  Oracle  appears  to  be  more  transportable  among 
different  makes  of  computer  systems.  Perhaps  the  ability  to  customize  the  user 
interface  was  a  strong  influence. 

GD  is  also  developing  baselines  for  program  output  in  order  to  test  for  valid 
data  when  a  combination  of  programs  are  used  within  RAMCAD. 

The  basic  concept  for  the  system  design  is  desirable,  but  how  acceptable  it  will 
be  for  the  user  will  determine  the  value  of  the  system.  At  this  point  of  the 
system  design,  we  should  be  researching  the  user  interface  requirements.  If 
the  interface  is  not  done  correctly,  the  software  can  be  excellent  and  the  system 
won't  be  used. 


Their  statement  about  IGES  suggests  to  us  that  they  should  look  at  IGES 
capabilities.  IGES  deals  with  the  key  question  of  how  to  move  information 
among  programs. 

RAMCAD  Advanced  Prototype  Data  Flow  diagram 

This  is  very  confusing,  since  it  is  hard  to  tell  how  the  system  interaction  takes 
place. 

7 .  February  1988  Status  Report 

(1)  Design  Process  Simulation 

When  reviewing  Mechanical  Advantage  by  Cognition,  were  any  of  the  team 
members  from  GD  Mechanical  Engineers  present? 

Another  question  for  Cognition  for  their  Expert  Cost  and  Manufacturing  Guide 
is,  "Can  it  take  into  account  an  individual  company's  specific  manufacturing 
processes  and  cost?"  Most  manufacturing  cost  packages  assume  a  process  and 
the  costs  associated  with  that  process.  Thus,  you  can  find  it  useful  only  for 
comparison  purposes  in  relation  to  the  software  programs  manufacturing 
process. 

(2)  Software  Survey 

No  comments. 

(3)  RAMCAD  System  Concept 

A  very  important  problem  in  relation  to  RAMCAD  was  presented  here,  that  of 
sufficient  data  on  the  electrical  parts  to  allow  modeling. 

The  problem  is  the  age  and  lack  of  information.  If  a  designer  is  working  with 
current  components  such  as  integrated  circuits,  they  must  have  the  necessary 
electrical  information  to  be  able  to  properly  integrate  into  the  design.  The 
example  they  referenced  was  for  a  555.  This  is  called  an  electronic  timer,  one 
of  the  most  common  integrated  circuits  in  production  today.  It  has  been  in 
production  for  ten  years  and  is  manufactured  by  at  least  three  different 
manufacturers.  If  an  integrated  circuit  that  is  so  common  as  this  is  not 
modeled,  then  the  systems  like  Mentor  Graphic  are  useless.  It's  like  having  a 
new  car  with  no  engine  and  you  have  to  research  the  engine  and  put  it  in  the  car 
yourself.  Next  you  find  that  there  are  no  wheels  and  you  have  to  research  and 
install  these.  This  goes  on  until  the  car  is  complete.  In  the  future,  if  all  your 
changes  to  the  car  design  always  use  exactly  the  same  parts,  okay,  but  if  a  new 
tire  comes  out,  you  again  have  the  same  problem. 
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8.  March  1988  Progress  Report 


(1)  RAMCAD  System  Concept 

More  detailed  work  is  progressing  on  the  advanced  prototype  with  discussion 
about  how  the  modules  will  talk  to  each  other.  There  is  also  discussion  about 
the  "human  factors"  aspect  of  the  system.  This  needs  to  be  examined  and 
should  be  a  critical  part  of  the  system  review.  However,  they  state  that  they 
are  going  to  use  some  of  the  same  people  they  interviewed  and,  more 
specifically,  Avionic  Engineers.  Is  this  the  best  sample  set?  Perhaps  not.  The 
RAMCAD  system  is  comprised  of  three  disciplines,  Electronic,  Mechanical, 
and  Structural.  Why  shouldn't  the  reviewers  be  from  these  disciplines,  not 
just  Avionics.  Also,  we  learned  at  SRR  that  the  engineers  who  were  involved 
in  the  survey  were  mostly  managers.  What  about  the  engineer  on  the  line 
doing  design  on  a  daily  basis,  not  just  reviewing  other's  work?  In  short,  the 
reviewers  should  be  more  diverse  in  their  backgrounds  and  not  just  those  who 
were  interviewed. 

The  discussion  as  to  what  will  be  the  "figures-of-merit"  remains  open. 

9.  April  1988  Progress  Report 

(l)  RAMCAD..System Concept 

The  discussion  of  2167  continues  as  GD  attempts  to  develop  a  tailored  version. 
The  review  of  the  tailored  version  (delivery  in  June  to  Air  Force  and  Army) 
and  its  acceptance  and  review  will  have  a  major  impact  on  this  program's 
progress.  We  need  to  keep  in  mind  that  this  is  to  be  used  as  a  guide  to  ensure 
sufficient  information  to  allow  others  to  leam  from  the  work  done  at  GD.  It 
appears  that  2167  requirements  were  added  out  of  naivety  on  the  part  of  the 
contract  officer,  not  by  originators  of  the  PRDA  itself.  There  is  a  lot  of  debate 
against  2167,  particularly  about  the  rigid  application  of  it  to  research  programs. 

10.  May  1988  -  RAMCAD  System  Concept 

The  2167  requirements  still  appear  to  be  taking  up  a  major  amount  of  their  time.  In 
talking  with  them,  it  appears  that  contract  language  and  the  CDRLs  are  not  in  sync  as  to 
what  they  must  do  to  satisfy  the  contractual  requirements.  The  CDRLs  are  less  flexible  as 
to  the  tailoring  of  2167.  The  Army  and  Air  Force  will  need  to  look  at  this  with  General 
Dynamics  to  help  ensure  resources  are  not  wasted.  The  formal  software  price  matrix 
discussed  has  not  been  delivered  to  IDA,  and  we  assume  it  is  only  for  contract  purposes. 


In  reference  to  the  networking  software  received,  it  appears  all  went  well.  I  am  sure  there 
were  problems  in  installing  the  software/hardware.  The  lessons  learned  here  may  be 
directly  usable  by  the  Army  and  Air  Force.  These  need  to  be  documented. 

In  their  discussion  in  reference  to  M-Spice,  we  assume  the  main  effort  of  work 
described  was  again  due  to  a  lack  of  electronic  parts  in  the  Mentor  library. 

11.  June  1988  -  RAMCAD  System  Concept 

The  data  base  is  growing  as  it  now  will  contain  both  the  inputs  given  to  an  analysis 
program  and  the  results  produced  when  those  inputs  are  acted  on.  An  interesting  question 
now  would  be  "How  long  will  this  information  be  stored  and  how  often  will  it  be 
updated?"  As  an  example,  an  engineer  makes  minor  changes  many  times  while  trying  to 
optimize  a  design.  Will  it  save  all  the  different  inputs/outputs  or  only  the  final  one,  or  the 
last  three,  or  etc.? 

The  work  on  the  user  interface  is  now  focusing  on  the  question,  how  to  make  it 
more  "user  friendly,"  but  where  are  the  discussions  as  to  user  needs!  Also,  if  we  are 
concerned  with  user  acceptance  (a  more  accurate  way  of  saying  "user  friendly"),  what 
about  an  industrial  psychiatrist.  The  folks  working  in  cockpit  design  may  offer  some 
relevant  suggestions. 

Under  the  paragraph  describing  what  software  "has  been  exercised  and/or 
validated":  let's  not  forget  that  Eagle  Technology's  Mechrel  is  a  demo  only  and  not  a 
functioning  software  tool. 

The  analysis  done  on  the  other  packages  by  GD  should  be  documented.  The 
lessons  learned  here  are  important  today. 

12.  July  1988  -  General  Dynamics  Review 

(l)  RAMCAD  System  Concept 

The  PDR  preparation  has  consumed  the  team's  time  this  month. 

However,  the  work  on  the  advanced  prototype  should  be  noted.  Time  is  being 
spent  validating  the  outputs  of  the  software.  This  is  critical  to  ensure 
acceptance  by  designers.  Any  designer's  attitude  when  they  first  work  with 
RAMCAD  will  not  be  one  of  comfort  for  two  primary  reasons.  First,  any 
method  that  differs  from  the  way  they  do  their  work  now  will  be  viewed  with 
some  misgivings,  even  if  they  are  now  using  computer-aided  tools  (if  they  are 


B-8 


not  using  any  computer-based  tools,  these  feelings  can  be  very  strong). 
Second,  there  will  be  a  reluctance  to  trust  the  system's  computations,  as  this 
system  will  appear  to  produce  results  on  its  own.  The  engineer  will  not  be 
manually  controlling  the  inputs  and  calculations.  One  incorrect  calculation  will 
cause  the  engineer  to  dismiss  the  RAMCAD  system's  usefulness. 

(2)  Program  Management 
No  comment 

(3)  Special  Programs/Equipment  Purchases/Constructed 

We  would  be  interested  in  finding  out  if  the  team  knows  why  DOS  would  not 
operate  under  Xenix  or  the  386  PC.  As  usual,  the  manufacturers  of  the 
equipment  tell  the  world  that  all  works  perfectly. 

In  discussions  with  Bill  Dawson,  we  understood  that  AIX  (the  IBM 
implementation  of  Unix)  was  very  buggy.  This  would  be  perhaps  acceptable 
for  the  prototype,  but  what  about  the  actual  system? 

(4)  Appendix  A  -  Lessons  Learned 

An  excellent  addition  to  the  report,  this  new  section  really  meets  the  objective 
of  RAMCAD.  This  month's  section  reflects  normal  development  events  and 
clearly  shows  progress. 

13.  August  1988  -  RAMCAD  System  Concept 
See  comments  under  SDR  review. 

(1)  Program. Management 

The  expiration  dates  for  the  software  on  loan  to  GD  are  before  the  projected 
time  for  the  contract  modifications  to  be  put  on  the  contract.  GD  could  very 
well  be  looking  at  a  stoppage  of  their  work  if  this  is  not  resolved. 

GD  commented  that  they  will  report  to  the  government  in  September  as  to  the 
status  for  extensions  on  the  loans  after  the  expiration  point  for  some  of  the 
software. 

(2)  Lessons  Learned  Problem  Summary 

B .  We  concur  with  the  government's  request  to  use  Oracle  due  to  the  fact  that 
it  is  already  in  use  by  the  sponsors  and  that  it  is  an  SQL-based  data  base 
as  was  Informix. 

D.  We  hope  this  additional  management  support  of  GD  will  lead  to  use  of 
RAMCAD  within  GD.  This  is  one  of  the  RAMCAD  program  goals. 
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14.  September  1988  -  RAMCAD  System  Concept 


Again,  we  see  a  major  limiting  factor  in  being  able  to  use  CAD  tools-the  lack  of 
component  information.  The  power  switching  amplifier  has  499  components  in  it.  Most 
of  the  needed  information  on  each  was  in  a  paper  form,  which  will  require  manual  entry.  It 
appears  that  for  a  company  to  have  an  electronic  CAD  or  CAE  system,  one  will  need  to 
have  at  least  one  full-time  person  just  to  keep  up  the  data  base. 

(1)  Lessons  Learned  Problem  Summary 

The  discussion  about  the  lack  of  electrical  component  information  should  be 
noted.  The  ability  to  get  the  information  from  other  data  bases  interactively  and 
not  having  to  reenter  it  is  logical.  The  hardest  part  will  be  knowing  when  to 
retrieve  this  in  a  manner  that  is  timely  (when  the  designer  needs  it)  and  with  a 
minimum  amount  of  delay.  The  closer  working  relationship  between 
government  and  industry  will  only  have  a  chance  of  working  when  industry 
resolves  its  disputes,  in  reference  to  their  technical  information  being  in  many 
printed  forms. 

GD's  realization  that  Mechrel  is  only  a  demo  is  accurate  and  one  that  IDA  has 
stated  before  to  the  government.  For  the  prototype  which  will  hopefully 
demonstrate  proof  of  concept,  it's  fine.  But  its  usefulness  for  a  functioning 
RAMCAD  system  is  in  serious  doubt 

B .  SEPTEMBER  1988  TO  SEPTEMBER  1989 

1 .  January  1989  -  RAMCAD  System  Concept 

As  work  continues,  we  are  encouraged  by  the  progress  reported  and  the 
understanding  of  the  need  to  perform  manual  checks  on  the  automated  system. 

The  Mechrel  program  still  plays  a  key  part  in  the  mechanical  design.  As  this  is  a 
demonstration  piece  of  software,  we  still  need  to  fill  this  void. 

2 .  February  1989 

The  main  progress  this  month  deals  with  the  presentation  of  the  program  at  PDR. 

A  draft  of  most  of  this  material  was  received  by  IDA,  HRL,  and  Picatinny  for  their 
comments  and  review.  Most  of  the  issues  raised  have  been  addressed  at  the  PDR  level  and 
are  being  updated  or  corrected. 
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The  most  significant  point  raised  is  that  GD's  work  has  now  progressed  to  the  point 
that  the  intent  of  the  original  PRDA  has  been  demonstrated--that  of  using  diversely  different 
"off-the-shelf  commercial  software  in  a  single  engineering  environment 

3.  March  1989 

Work  continues  on  the  integration  of  the  comments  and  direction  given  at  the  PDR. 
Work  is  also  progressing  on  the  draft  of  the  software  requirements  specifications. 

4.  April  1989 

Since  Mentor  Graphics  has  discontinued  support  of  the  M-Spice  Plus  (circuit 
simulation  tool)  which  was  used  in  the  advance  prototype,  ACCUSIM  has  been  added  to 
replace  it.  We  should  document  in  lessons  learned  the  problems  and  methods  used  to 
convert  the  data  files  as  there  may  be  others  in  the  future  who  will  have  a  need  to  do  so. 

The  discussion  of  integrating  RAMCAD  into  the  GD  internal  program  of  Integrated 
Manufacturing  System  (IMS)  is  most  encouraging.  The  GD  program  has  always  needed 
more  user  input  from  the  engineering  departments. 

5.  May  1989 

A  great  deal  of  time  and  work  has  gone  into  the  software  requirements 
specifications.  GD  has  put  a  large  amount  of  work,  organization,  and  detail  in  the  draft  of 
the  SRS  (final  release  was  due  on  15  June  1989). 

6 .  June  1989 

The  training  that  is  being  performed  by  GD  should  be  observed  by  the 
programmers  responsible  for  the  user  interface.  Careful  notes  should  be  taken  as  to  any 
distractions  and/or  problems  noted  by  the  users.  New  users  have  the  advantage  of  trying 
things  on  the  system  in  the  way  they  perceive  they  should  logically  work. 

C.  MILESTONE  REVIEWS 

1.  Systems  Requirements  Review  (SRR) 

On  March  15-16,  1988,  the  Air  Force,  Army,  and  IDA  attended  the  SRR  at  General 
Dynamics.  This  was  the  first  major  milestone  in  the  GD  RAMCAD  program. 
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The  Review  covered  four  primary  areas,  Design  Process  Simulation,  Reliability, 
Maintainability  and  Supportability  Software  Survey,  and  the  RAMCAD  System  Concept 
and  Project  Management. 

The  first  of  these  areas  (Design  Process  Simulation)  was  to  determine  how  or  what 
process  is  used  by  designers  at  GD  to  create  a  new  design.  This  was  believed  to  be 
necessary  because  one  cannot  improve  upon  a  process  unless  one  knows  how  the  work  is 
conducted.  This  was  accomplished  by  GD  interviewing  73  engineers  from  18  different 
design  groups.  A  large  number  of  the  designers  were  supervisors.  As  a  result  of  this,  the 
government  recommended  that  the  number  of  day-to-day  designers  be  increased  to  ensure 
the  results  represented  the  current  GD  process. 

After  this  survey  the  team  looked  for  a  common  figure  of  merit  to  allow  trade-off 
considerations  to  be  done  between  different  design  disciplines  (electrical,  mechanical,  and 
structural).  Their  recommendations  were  to  use  mean  time  between  failure  (MTBF)  to 
measure  reliability,  mean  time  to  repair  (MTTR)  to  measure  maintainability,  and  operations 
and  support  (O&S)  cost  with  repair-level  determination  to  assess  supportability. 

This  approach  has  raised  many  questions,  in  part  because  the  government  has 
found  that  MTBF  is  a  term/concept  that  is  not  acceptable  to  the  mechanical  engineering 
community.  The  concept  of  integrating  the  three  disciplines  is  critical  if  RAMCAD  is  to 
progress  beyond  being  a  "design  checking"  tool. 

RM&S  Software  Survey 

A  survey  of  RM&S  computer  programs  available  on  the  commercial  market  was 
performed.  Those  programs  considered  in  the  survey  must  be  currently  available  to  anyone 
who  wishes  to  purchase  them.  Government-owned  or  -sponsored  packages  were 
considered  if  they  were  generally  available.  (RAMCAD  was  to  allow  industry  to  change 
the  way  they  design  products,  thus  yielding  better  systems  to  the  government.)  The 
software  survey  team  reviewed  153  software  packages  and  documented  their  findings.  The 
following  programs  were  selected,  in  some  cases  because  they  were  the  best  and  in  others 
because  there  was  no  other  choice. 

( 1 )  RelPlus  from  Prophet  Software  (Electronic  Reliability) 

(2)  Mechrel  from  Eagle  Technology  (Mechanical  Reliability,  217D) 

(3)  I-Deas  from  SDRC  (Structural  Reliability) 
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(4)  MPP  from  Powertronics  Systems  (EM&S  Reliability) 

(5)  NRLA  from  AF  Acquisition  Logistics  Center  (EM&S  Supportability). 

Mechanical  Advantages  planned  improvements  may  allow  it  to  be  supplemented  if  Mechrel 
does  not  materialize. 

The  major  conclusion  from  this  survey  is  the  lack  of  good  software  tools  for  the 
mechanical  engineering  community.  This  task  in  their  contract  will  be  continued 
throughout  the  contract 

System  Concept 

This  was  the  preliminary  idea  for  the  RAMCAD  system.  The  primary  focus  was 
from  a  programmer's  perspective,  i.e.,  on  the  computers  and  the  operating  systems  that 
may  be  used  in  the  prototype.  The  focus  is  still  on  integrating  the  three  disciplines, 
mechanical,  structural,  and  electrical.  At  this  point  it  appears  that  Unix  with  X-Windows 
will  be  the  operating  system.  This  will  help  ensure  the  ability  to  move  from  one  hardware 
platform  to  another. 

Program  Management 

This  final  part  of  the  SRR  addressed  items  of  a  contractual  nature  only. 

2 .  System  Design  Review  (SDR) 

The  SDR  was  held  on  August  10-11,  1988. 

After  the  review  of  the  materials  presented  at  SDR  and  the  discussions  that  took 
place  we  have  noted  a  list  of  issues  that  still  needs  to  be  addressed. 

Concerns  for  SDR  (System  Design  Review) 

•  "General  System  Architecture" 

Reflects  the  basic  General  Dynamics  approach.  Three  standalone  "RAMCAD" 
systems  with  limited  interaction  among  the  three.  The  primary  interaction 
among  the  three  is  the  users’  interface.  All  three  share  the  data  file,  sometimes 
using  the  translators  for  interpretation  and  formatting  of  the  data. 

*  System  Design  Review:  Advanced  Prototype  Software 

Third  paragraph  down  reinforces  our  concern  as  to  the  degree  of  engineering 
input.  When  a  designer  is  specifying  a  component  such  as  a  resistor  he  does 
not  normally  worry  about  wattage  when  he  or  she  is  deciding  on  a  value  for  it. 
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Their  focus  is  getting  the  schematic  in  their  head  on  paper  or  screen  and 
looking  to  see  if  the  circuit  will  function.  The  computations  for  wattage  are 
done  after  the  fact  and  usually  by  someone  other  than  the  designer  (junior 
engineer  or  senior  draftsman)  unless  the  component  size  is  critical.  Even  then 
it  is  usually  checked  by  the  designer  after  someone  else  has  done  the 
calculations. 

•  Heavy  emphasis  on  solid  modeling 

We  have  reservations  about  the  importance  and  the  priority  placed  on  this.  Are 
we  letting  the  "oo's"  and  "aa's"  of  graphics  get  in  the  way  of  our  objectives? 

•  Is  "mechanical  advantage"  the  best  package  to  be  using? 

As  this  is  a  package  still  under  development  at  Fort  Belvoir,  Virginia,  are  we 
aware  of  how  their  proposed  changes  will  affect  the  usefulness  of  this  software 
in  the  future? 

•  In  a  constantly  changing  environment  of  hardware  and  software,  what  plan  do 
they  proposed  to  ensure  our  awareness  and  theirs  as  to  what  is  happening  in 
industry  and  the  government?  Aren't  they  supposed  to  be  tracking  this  and 
reporting  back  to  us  on  what  they  are  finding?  It  has  been  more  than  half  a 
year  since  their  original  study  was  done;  a  great  deal  has  happened,  and  yet  we 
have  received  no  information. 

•  Data  Base  Management  System 

We  are  glad  to  see  their  emphasis  on  SOL  as  it  comes  as  close  as  anything  else 
to  a  common  data  base  language.  Informix  is  clearly  one  of  the  "major"  data 
bases  for  serious  data  needs.  As  to  the  question  of  Informix  versus  others, 
such  as  Oracle  (which  as  just  been  released  for  the  IBM  and  Mac  systems),  we 
find  that  programmers  tend  to  have  a  love-hate  relationship  with  the  programs. 
If  it  is  the  one  they  use  and  know  they  believe  it  to  be  best,  and  the  others  tend 
to  have  "problems"  in  their  mind.  The  rationale  for  choice  seems  the  best 
given  their  imposed  restraints.  If  new  data  bases  come  out  which  prove  to  be 
better,  they  could  transition  to  another  SQL-based  data  base  when  it  makes 
sense. 

•  Display  on  the  Workstation 

There  appears  to  be  a  lack  of  inputs  from  multiple  users  of  the  workstation  and 
the  process  of  its  development  The  most  noticeable  is  the  same  mistake  TRW 
made  in  their  system-the  display  was  designed  by  the  programmer,  not  the 
user!  The  letters  and  words,  for  example,  are  too  small  for  the  average  user. 
This  is  the  classic  mistake  most  programmers  make  on  large  display  screens. 
One  tends  to  focus  on  the  larger  display  area  that  is  available  for  information 
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display  and  gets  caught  up  in  displaying  as  much  information  as  they  can 
squeeze  into  the  area. 

Two  factors  need  to  be  considered  here.  One  is  how  much  information  can 
one  mdivid”al  work  with  comfortably  on  any  screen  at  one  time  and  yet  not  be 
distracted  by  more.  The  second  is  fatigue;  the  display  on  a  color  screen  due  to 
the  physics  involved  is  not  as  clear  as  the  same  size  screen  on  black  and  white, 
thus  the  information  displayed  must  be  constructed  to  reduce  fatigue. 
Techniques  such  as  larger  letters,  contrasting  colors,  limited  number  of  colors 
(the  natural  tendency  is  to  "make  it  as  spectacular  as  possible"  with  256 
colors),  and  consistency  of  color  to  meaning  are  some  of  the  factors  to  be 
considered.  The  displaying  of  information  in  a  manner  to  maximize  the 
information  being  communicated  is  itself  a  science. 

•  The  use  of  MTBF  for  structural  analysis 

The  structural  community  and  some  academics  of  this  discipline  have  all 
expressed  their  concerns  with  MTBF  being  applied  to  the  physics  of  failure  of 
materials.  Are  we  perhaps  using  this  as  an  easy  means  of  communications 
among  software  packages  and  avoiding  the  more  difficult  problems  of  failure 
analysis? 

•  The  electronic  R&M  analysis  station  is  totally  based  on  217  analysis 
techniques.  These  techniques  are  under  some  attack  when  applied  to  complex 
assemblies,  and  a  different  approach  may  well  be  developed  in  the  next  few 
years.  Provisions  should  be  made  for  utilizing  other  techniques  as  they 
appear. 

The  mechanical  and  structural  R&M  analyses  are  partly  dependent  on  analysis 
techniques  that  do  not  have  general  acceptance  in  the  mechanical/structural 
design  field.  Here  also  provisions  should  be  made  for  incorporating  other 
techniques  as  may  be  decided  later. 

•  The  contract  specifies  using  commercially  available  software  without  any 
alterations.  This  limits  the  ability  to  make  interactive  trade-offs  which  are 
required  for  a  design  tool  vis-a-vis  an  R&M  analysis  tool.  For  example, 
trading  thermal  placement  requirements  with  routing  placement  requirements  is 
a  long-winded  iterative  process  if  the  only  way  to  do  it  is  to  run  a  complete 
thermal  analysis,  then  a  complete  routing  analysis  repetitively.  To  optimize  the 
interaction  would  appear  to  require  tampering  with  the  source  code  which  is 
prohibited  by  the  contract  even  if  the  vendor  gave  permission.  There  may, 
therefore,  be  technical  limitations  in  trying  to  make  a  design  tool  out  of 
unaltered  R&M  analysis  packages. 
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3 .  Preliminary  Design  Review  (PDR) 

a.  Overview 

The  Preliminary  Design  Review  (PDR)  represents  a  major  milestone  in  the  research 
and  development  of  the  RAMCAD  system.  It  was  held  on  February  22-23,  1989,  at 
General  Dynamics.  Approval  of  the  preliminary  design  releases  General  Dynamics  to 
move  forward  with  their  concept  for  the  development  of  a  fully  functional  system. 

The  functional  system  is  based  on  the  prototype  system  discussed  and  demonstrated 
at  the  System  Design  Review  (SDR). 

The  functional  system  will  be  based  on  the  use  of  computers  produced  by  Apollo, 
EBM,  and  Digital  Equipment  Corporation.  These  systems  will  be  able  to  communicate  and 
exchange  information  via  a  network  based  on  Ethernet  The  ability  to  exchange  data  is  a 
necessity  for  the  different  programs  to  be  able  to  use  the  work  accomplished  by  the  other 
programs.  The  central  storage  for  this  information  will  be  developed  around  a  data  base 
system  called  Oracle.  Oracle  will  store  the  information  necessary  for  the  modules,  called 
translators,  developed  by  General  Dynamics.  These  translators  do  just  what  the  name 
implies.  They  translate  the  information  from  a  generic  format  for  the  data  in  Oracle  to  the 
specific  format  needed  by  the  program  requesting  the  information.  These  translators  are 
bidirectional,  thus  allowing  new  information  to  be  stored  in  the  master  data  base.  All  of  the 
design  tools,  both  commercial  and  those  developed  by  General  Dynamics,  are  able  to  utilize 
the  information  stored  in  the  master  data  base,  either  directly  or  with  the  assistance  of 
translators. 

The  data  base  also  controls  the  access  to  each  of  the  commercial  software  programs 
through  its  user  interface.  This  is  done  for  two  reasons:  (1)  to  give  the  user  a  common 
reference  point  for  accessing  each  package  of  software  on  the  system;  and  (2)  to  ensure  that 
the  computer  system  knows  exactly  where  the  user  is  and  what  they  want  to  do.  By 
requiring  that  the  user  go  through  this  common  point,  the  system  retains  control  whenever 
the  user  goes  into  the  system.  Thus,  it  will  allow  the  RAMCAD  system  designers  to 
ensure  such  things  as  the  correct  translator  being  in  place  when  it  is  necessary.  Control  on 
the  General  Dynamics'  system  by  a  central  master  program  will  allow  the  user,  in  the 
future,  to  insert  new  or  better  software  into  RAMCAD  for  use  by  its  designers. 
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b.  IDA  Review  of  PDR  Presentations 

The  basic  system  concept  as  proposed  was  accepted  at  the  SDR  and  now  the  details 
of  the  actual  approach  muc*  be  dealt  with  at  PDR.  Our  major  concern  was  with  the  lack  of 
data  for  the  physical,  mechanical,  and  electronic  components.  This  information  can  be 
found  in  printed  form  but  not  necessarily  in  an  electronic  format.  The  other  half  of  this 
problem,  if  the  data  were  to  be  made  available  by  the  manufacturers  of  the  particular 
component,  is  "what  information  is  needed  and  in  what  format?" 

Each  piece  of  software  to  be  used  to  assist  a  designer  has  specific  information 
needs.  Some  of  this  information,  such  as  that  which  needs  to  be  calculated,  can  be  done  by 
the  RAMCAD  system  through  the  translators,  but  these  calculations  require  certain 
information.  This  problem  has  been  with  us  for  years— that  of  what  form  and  format  this 
data  should  be  in.  IDA  addresses  this  issue  in  a  report  on  the  competing  standards  being 
proposed  to  attempt  to  solve  this  problem.  There  is  still  no  single  solution  to  this  today. 

The  first  half  of  this  problem  is  the  reluctance  of  manufacturers  to  release  this 
information.  As  an  example,  in  the  integrated  circuits  manufacturing  market  there  are 
hundreds  of  books  published  each  year  by  the  various  manufacturers  and  others  on  the 
specifications  for  their  integrated  circuits.  There  have  also  been  hundreds  of  thousands  of 
different  integrated  circuits  produced.  Consequently,  the  volume  of  information  is 
staggering.  Programs  such  as  CALS  are  testing  this  very  problem,  with  the  massive 
amount  of  information  that  is  generated,  to  attempt  to  put  it  in  a  common  form  that  in  the 
future  will  allow  rapid  access  and  still  be  current  information. 

How  does  a  company  such  as  Valid  or  Mentor  Graphics  handle  this  for  their 
electrical  design  system  customers  that  require  this  type  of  information?  They  allow  the 
customer  to  research  the  information  on  a  component-by-component  basis,  and  manually 
enter  it  into  their  systems  data  base  in  their  own  form  and  format.  This  information  is 
usually  obtained  through  a  parts  specification  catalog  published  by  the  original 
manufacturer  of  the  integrated  circuit 

There  has  been  some  progress  in  this  area  as  a  small  number  of  companies  are 
entering  information  on  the  more  commonly  used  integrated  circuits  into  each 
manufacturer’s  data  base,  and  reselling  their  labor  for  owners  of  such  systems  to  use.  The 
most  common  solution  for  owners  of  these  design  systems  is  to  hire  an  individual  who  is 
responsible  for  the  maintenance  and  updates  to  the  designer’s  system.  As  a  result,  the 
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systems  tend  to  contain  information  on  components  used  on  past  designs.  Thus,  an 
engineer  will  be  forced  to  do  the  conceptual  and  some  preliminary  design  in  their  mind  with 
new  components.  Only  after  the  design  is  fixed  in  their  minds  will  they  test  their  concept 
on  the  system  after  the  data  on  the  new  components  is  entered. 

This  is  a  problem  to  be  addressed  and  highlighted  by  the  RAMCAD  program  but  is 
not  within  its  scope  to  attempt  to  solve.  [Reference— ML  Brei’s  paper  on  "Data  Exchange 
Standards."] 

Our  next  concern  is  with  the  lack  of  commercially  available  software  for  the 
mechanical  engineers  to  use  in  their  analysis  work.  If  we  look  at  the  current  RAMCAD 
program  we  see  software  such  as  Mechrel  Plus  being  used  to  fulfill  a  particular  need.  Yet 
we  are  aware  that  this  is  only  a  demonstration  program  and  the  calculations  which  are 
introduced  by  Mechrel  Plus  are  in  error.  Mechanical  reliability  has  not  been  addressed  by 
the  commercial  and  computer  industry  as  thoroughly  as  has  the  area  of  electronic  design. 
GD  is  attempting  to  bring  before  the  designer  information  on  the  electrical,  structural,  and 
mechanical  aspects  of  their  active  designs.  This  requires  a  balanced  view,  but  a  balanced 
view  is  not  possible  if  the  analysis  tools  are  not  available. 

Another  important  issue  is  the  User  Interface.  When  we  observe  the  actual 
computer  screen  and  the  way  it  would  be  operated  by  a  designer  (user  interface),  we  note  a 
lack  of  commonality  with  the  computer  industry  and  its  approach.  We  believe  that  GD 
needs  to  do  more  research  into  the  design  of  user  interfaces  and  that  they  also  need  more 
input  from  the  design  community  that  would  use  such  a  system  within  GD.  We  are 
speaking  of  the  actual  day-to-day  users,  not  the  supervisors  or  managers.  If  the  user  does 
not  accept  the  presentation  method  for  the  information  relating  to  their  design  or  if  they  find 
it  tiring,  they  will  not  use  the  system.  The  user  interface  is  as  critical  as  the  software 
programs  performing  the  analysis. 

Our  last  concern  is  with  the  problem  of  how  to  go  about  the  integration  of  the 
mechanical,  structural,  and  electrical  aspects.  By  integration,  we  mean  the  ability  to  see  the 
effect  of  a  change  made  in  one  discipline  upon  the  others.  It  is  critical  for  the  full 
development  of  a  RAMCAD  system  that  this  issue  be  addressed.  If  we  ignore  the  issue  of 
being  able  to  make  trade-offs  among  the  different  disciplines,  then  we  end  up  with  a  fancy 
system  for  design  checking. 
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c.  Summary  Comments  on  the  PDR 

It  appears  that  what  General  Dynamics  has  developed  is  a  workstation  that  enables 
an  R&M  engineer  to  do  his  work  more  rapidly.  This  accomplishes  one  goal  of  RAMCAD, 
i.e.,  to  reduce  the  turnaround  time  for  R&M  analysis  of  designs  from  two  to  three  weeks  to 
a  few  minutes  (given  a  tie-in  to  the  CAD  system). 

To  satisfy  the  rest  of  the  Task  I  goals,  this  could  be  made  into  a  design  tool  (i.e., 
actually  become  a  part  of  the  CAD  process  used  by  designers)  if  more  attention  was  paid  to 
the  executive  controller  and  the  man/machine  interface  in  order  to  satisfy  the  designer's 
needs.  To  date,  the  designer's  input  has  been  minimal,  and  designers  need  to  be  more 
directly  involved  in  the  RAMCAD  development  process.  (An  approach  such  as  TRW's 
rapid  prototype  might  be  useful.) 

General  Dynamics  has  an  electronic  system  R&M  analysis  station  demonstration 
and  the  detailed  plans  for  mechanical  and  structural  R&M  analysis  stations.  Thus,  the 
goals  of  Task  I  have  been  shown  to  be  attainable  and  have  been  partly  achieved. 

It  is  our  position  that  the  PRDA  was  never  intended  to  be  carried  out  as  separate 
tasks  by  separate  contractors.  Task  I  was  intended  to  be  a  rapid  demonstration  of  what 
could  be  done  to  tie  R&M  analysis  into  the  design  process  using  commercially  available 
hardware  and  software.  This  demo  was  felt  to  be  necessary  in  order  to  provide  a  baseline 
and  momentum  for  Task  II,  which  would  address  the  question  of  using  advanced 
technology  and  advanced  ideas  from  lessons  learned  in  Task  I.  This  was  done  in  order  to 
attack  the  fundamental  problem  of  integrating  R&M  requirements  and  analysis  into  all 
phases  of  design. 

The  next  phase  of  General  Dynamics  development  work  will  start  to  address  some 
of  the  issues  for  Task  II. 
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Appendix  C 


INITIAL  CALS  IMPLEMENTATION  PLAN 


EXECUTIVE  SUMMARY 

A .  THE  TASK  FORCE  CHARTER 

In  April  1974  Under  St:retary  of  Defense  DeLauer  and  Assistant  Secretary  of 
Defense  Korb  issued  a  memorandum  which  tasked  the  Institute  for  Defense  Analyses 
(EDA)  to  assemble  a  task  force  of  senior  industry  and  government  logisticians  to  address 
the  problems  faced  by  DoD  in  applying  new  and  emerging  computer  technology  to  improve 
the  logistics  support  process.  The  task  force  was  given  a  charter  to  "develop  a  strategy  and 
a  recommended  master  plan  for  computer-aided  logistic  support."  The  task  force  was 
formed  and  held  an  intensive  series  of  meetings  throughout  the  last  half  of  1984,  during 
which  time  this  report  was  prepared. 

The  DeLauer/Korb  instruction  was  generated  by  a  perception  in  OSD  that  there  was 
an  important  opportunity  to  coordinate  the  rapidly  expanding  automation  of  support 
functions  in  the  Services  and  the  Defense  Logistics  Agency  with  the  efforts  in  segments  of 
the  defense  industry  to  achieve  "near-paperless"  design,  engineering,  manufacturing,  and 
logistics  planning  operations.  Through  integration  of  automated  reliability  and 
maintainability  analysis  into  initial  computer-aided  design,  better  supportable  weapon 
systems  can  be  designed  and  manufactured.  There  are  also  enormous  potential  benefits  in 
logistics  efficiency  if  the  product  definition  and  technical  data  which  manufacturers  generate 
in  digital  form  could  flow  to  all  users  in  the  support  system  without  the  hardcopy  paper 
links  that  are  now  used  to  transmit  information.  The  CALS  Task  Force  confirmed  these 
perceptions,  and  developed  program  objectives  and  a  strategy  to  take  advantage  of  this 
opportunity. 
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B  .  CALS  PROGRAM  OBJECTIVES 


Working  in  cooperation  with  the  defense  industry,  other  government  agencies,  and 
professional  and  industrial  associations,  the  Department  of  Defense  should  take  immediate, 
positive  action  making  use  of  current  and  emerging  computer  technology  to: 

•  Design  more  supportable  weapon  systems. 

•  Transition  from  paper-based  to  digital  logistics  and  technical  information. 

•  Routinely  acquire  and  distribute  logistics  and  technical  information  in  digital 
form  for  new  weapon  systems. 

These  objectives  cannot  be  achieved  immediately.  But  by  following  a  strategy  of 
near-term,  mid-term,  and  long-term  actions,  DoD  can,  within  five  years,  have  in  place  a 
program  for  receipt  and  distribution  of  logistics  products  in  digital  form  for  all  major 
weapon  systems  entering  production.  By  taking  immediate  action  at  the  DoD  level  to 
define  and  adopt  a  complete  set  of  data  exchange  standards,  and  to  develop  overall 
architectural  guidelines  for  automation  of  technical  information  throughout  the  Military 
Departments,  DoD  can  establish  the  unified  interface  requirements  which  will  enable 
industry  to  accelerate  its  own  automation  initiatives.  The  Military  Services  already  have 
programs  in  being  that  represent  important  building  blocks  in  this  effort;  these  programs 
should  be  strengthened  and  extended.  Service  implementation  plans  should  be  developed 
to  integrate  these  individual  building  blocks  into  a  complete  network  for  digital  distribution, 
processing,  and  use  of  the  logistics  information  delivered  by  industry. 

In  parallel  with  these  actions  to  automate  the  development  and  distribution  of 
logistic  support  products,  DoD  and  industry  should  both  take  aggressive  action  to  better 
use  computer  technology  to  improve  weapon  system  supportability  by  integrating  reliability 
and  maintainability  (R&M)  analysis  into  the  initial  design  process.  This  is  also  a  central 
thrust  of  logistics  support  analysis  (LSA),  and  a  CALS  program  will  provide  improved 
tools  for  accomplishing  LSA  objectives.  Industry  has  the  principal  responsibility  for 
incorporating  these  automated  analysis  tools  into  its  computer-aided  design  and  engineering 
(CAD/CAE)  processes.  However,  DoD  must  provide  the  design  requirements  and  contract 
incentives  needed  to  guide  industry  efforts.  R&D  and  IR&D  priority  must  be  given  to 
meeting  this  objective. 

The  strategy  recommended  by  the  CALS  Task  Force  provides  a  phased  program  of 
individual  initiatives  designed  to  support  achieving  these  CALS  objectives.  By  fully  and 
formally  committing  DoD  to  these  objectives,  and  the  strategy  for  accomplishing  them,  the 
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OSD  sponsors  of  this  study  can  inaugurate  significant  and  far-reaching  improvements  in 
the  acquisition  and  logistics  management  of  future  defense  programs. 

C .  RECOMMENDED  STRATEGY  AND  IMPLEMENTATION 
MANAGEMENT 

The  Task  Force  recommends  that  a  DoD  policy  be  established  that  will  both  direct 
and  encourage  the  integration  of  existing  "islands  of  automation"  and  facilitate  the  transition 
of  logistics  processes  within  DoD  and  industry  from  paper-based  to  digital  mode  in  an 
orderly  way.  The  policy  should  stress  the  need  for  each  DoD  component  to  develop  a 
phased  plan  for: 

•  Demonstrations  and  incentives  to  integrate  R&M  into  CAE/CAD  and  to 
automate  supportability  design  analysis. 

•  Adoption  of  DoD- wide  interfacing  standards  and  neutral  data  formats. 

•  Instituting  pilot  programs  to  integrate  selected  logistics  functions  into  segments 
of  a  CALS  system,  while  concurrently  requiring  that  weapon  program  new 
starts  plan  to  utilize  digital  support  data. 

•  Establishing  DoD- wide  coordination  toward  a  planned  CALS  architecture. 

For  each  of  these  thrusts,  a  plan  of  action  was  developed  and  is  presented  below. 

To  implement  the  planned  actions,  a  management  office  should  *be  established  in 
each  Service  and  in  DLA  with  responsibility,  authority,  and  resources  for  coordination  of 
all  four  thrust  areas.  While  each  DoD  component  should  develop  a  CALS  implementation 
plan  that  best  meets  its  individual  requirements,  development  of  a  unified,  DoD-wide 
interface  with  industry  is  also  needed.  There  arc  various  options  for  effecting  the  necessary 
overall  coordination  among  the  Services  and  DLA.  The  Task  Force  felt  that,  at  the  least,  a 
DoD  Steering  Group  should  be  established  at  the  senior  Service  level  with  members  from 
OSD,  the  Services,  and  other  DoD  agencies.  This  group  should  be  charged  with  (1) 
maintaining  communication  between  the  individual  management  offices  in  each  Service  and 
in  DLA,  (2)  maintaining  a  continuing  dialogue  with  industry  regarding  CALS  plans  and 
programs,  (3)  overseeing  the  establishment  of  interfacing  standards  and  neutral  data 
formats,  and  (4)  evolving  an  overall  CALS  architecture.  An  alternative  supported  by  a 
portion  of  the  Task  Force  was  an  OSD  program  office  with  a  full-time  staff  and  the  funding 
authority  needed  to  provide  more  centralized  control  and  direction  of  the  CALS  program. 
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D .  RECOMMENDED  PLAN  OF  ACTION 


1 .  Plan  for  Thrust  1— Integration  of  Automated  R&M  and  Supportability 
Analysis  into  Design 

a.  Findings 

•  Reliability,  maintainability,  and  supportability  (RM&S)  analyses  are  not  part  of 
the  engineering  design  mainstream. 

•  Technology  for  integrating  RM&S  into  computer-aided  design  exists. 

b.  Recommended  Actions 

•  Formalize  inter-Service  coordination  through  a 
Memorandum  of  Agreement 

•  Develop  new  RM&S  tools. 

•  Publish  plan  to  expand  applications  through 
incentives,  contract  requirements,  and  R&D. 

•  Publish  catalogue  of  RM&S  tools. 

•  Establish  Centers  of  Excellence  for  demonstration 
of  integrated  supportability  design  analysis. 

2 .  Plan  for  Thrust  2-Interfacing  Standards  and  Neutral  Data  Formats 

a.  Findings 

•  Interim  standards  are  available  and  are  already  being  adopted. 

•  Near-term  and  long-term  DoD  goals  do  not  exist 

•  Current  DoD  policies  do  not  support  minimum  needs  for  DoD-wide  standards. 

b.  Recommended  Actions 

•  Establish  DoD  plan  and  schedule.  Immediately 

•  Interfacing  standards 

--  Policy  on  specific  interim  standards  July  1985 

—  Adopt  specific  product  definition  standard.  Summer  1986 


Immediately 

Ongoing 
September  1985 

June  1986 

January  1986 
to  January  1989 
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Data  Standards 


--  Publish  information  management  and  access  December  1985 

standard 

—  Publish  initial  CALS  data  element  dictionary  January  1986 

~  Publish  expanded  CALS  data  element  dictionary.  January  1987 

3.  Plan  for  Thrust  3<«Pilot/Demonstration  Program 

a.  Findings 

•  Integration  of  functions  introduces  need  for  procedural  changes,  retraining, 
and  reassignment  of  personnel. 

•  Pilot  programs  are  needed  to  demonstrate  the  benefits  of  CALS  initiatives  in  an 
operational  environment  and  to  obtain  user  feedback  for  future  system  design. 

b.  Recommended  Actions 

•  Initiate  pilot  programs  to  integrate  ongoing  Service  January  1986 

programs  and  demonstrate:  to  January  1989 

-  Digital  delivery  and  use  of  engineering  data 

~  Automated  authoring  and  updating  of  technical 
documentation 

-  Interactive  training  and  maintenance  aids 

—  Automated  LSA  data  and  LSA  reports. 

•  Each  Service  designate  a  "lead  the  force"  acquisition  1985  to  1995+ 

program  to  demonstrate  use  of  digital  data  from  the 

acquisition  cycle  through  to  field  use. 

•  DoD  should  coordinate  these  pilot  programs  to  demonstrate  functional  use  of 
the  specified  interfacing  standards  and  neutral  data  formats. 

•  All  weapons  program  new  starts  should  plan  to  utilize  digital  support  data  to 
the  maximum  extent  possible. 

4 .  Plan  for  Thrust  4— DoD-Wide  Coordination  Toward  a  Planned  CALS 
Architecture 

a.  Findings 

•  Integration  of  automated  functions  requires  a  plan  and  management 
coordination. 

•  DoD-wide  architectural  guidelines  do  not  exist 
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b.  Recommended  Actions 

•  Issue  DoD  planning  guidelines. 

•  Services  and  DLA  publish  phased  system 
development  plan. 

•  Services  and  DLA  publish  initial  CALS  architecture. 

•  DoD- wide  coordination. 

•  Pilot/demonstration  programs  (see  thrust  3). 


Immediately 
December  1985 

March  1986 

June  1986 

January  1986 
to  January  1989 


E.  CONSOLIDATED  SCHEDULE 

Figure  ES-1  gives  a  consolidated  schedule  for  the  thrusts  detailed  above.  In 
combination,  this  strategy  will  provide  at  the  end  of  five  years  all  the  tools  and 
demonstrated  "building  blocks"  needed  to  initiate  a  fully  integrated  Computer-Aided 
Logistic  Support  program  for  all  major  and  less-than-major  systems  entering  production. 
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Figure  ES-1.  Consolidated  Schedule 
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THE  TQM  INITIATIVE 


THE  UNDER  SECRETARY  OF  DEFENSE 


acquisition 

(P&L/PS) 


WASHINGTON.  OC  20301 


l  9  AUG  t989 


MEMORANDUM  FOR  SECRETARIES  OF  THE  MILITARY  DEPARTMENTS 

ASSISTANT  SECRETARY  OF  DEFENSE  (PRODUCTION 
AND  LOGISTICS) 

DIRECTORS  OF  DEFENSE  AGENCIES 

SUBJECT:  Implementation  of  Total  Quality  Management  in  DoD 

Acquisition 


The  Department  of  Defense  is  facing  one  of  the  most 
challenging  periods  in  its  history.  We  must  maintain  the  important 
gains  in  readiness  already  made  and  at  the  same  time  continue 
steady  improvement  in  the  face  of  greater  austerity,  increasing 
technological  complexity,  and  a  growing  diversity  of  threats.  We 
believe  that  Total  Quality  Management  (TQM)  can  provide  the 
leverage  to  meet  these  unparalleled  challenges.  I  am  convinced 
that  by  implementing  TQM,  and  by  coupling  it  with  the  intensified 
application  of  such  value-added  strategies  as  Acquisition 
Streamlining,  Transition  from  Development  to  Production,  Could 
Cost,  and  others,  we  can  achieve  unprecedented  improvements  in  the 
effectiveness  of  the  DoD  acquisition  process. 

I  want  TQM  applied  to  the  acquisition  of  defense  systems, 
equipment,  supplies,  facilities,  and  services  to  ensure  continuous 
improvement  of  products  and  services  being  provided  to,  and  by,  the 
Department  of  Defense.  The  principles  outlined  in  the  March  30, 
1988,  DoD  Posture  on  Quality  will  guide  TQM  implementation  efforts. 
A  suggested  definition  of  TQM  is  shown  in  attachment  1. 

I  am  making  TQM  success  my  primary  objective.  We  will  link 
TQM  to  the  weapon  system  decision  process  to  ensure  that  it  is 
properly  considered  in  acquisition  strategy  development  and 
effectively  implemented  during  contract  execution.  To  this  end,  I 
am  requesting  that  the  Defense  Acquisition  Board  (DAB)  act  as  the 
DoD  steering  group  for  TQM  implementation  in  acquisition.  The 
initial  DAB  meeting  on  TQM  implementation  will  follow  the  senior 
level  awareness  training  session  scheduled  for  August  18,  1988.  A 
specific  agenda  will  be  forwarded  under  separate  cover. 

One  of  the  earliest  agenda  items  will  be  to  approve  and  issue 
a  DoD  implementation  strategy  for  acauis i t ion  and  identify 
acquisition  improvement  objectives.  The  TQM  strategy  will  serve  as 
a  basis  for  formulation  of  individual  Service  and  Agency 
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implementation  plans.  Mr.  Jack  Strickland,  Director  Cor  Industrial 
Productivity  and  Quality,  staff  lead  for  TQM,  is  developing  a 
"strawman"  of  the  TQM  strategy.  Copies  will  be  circulated  for  your 
review  in  advance  of  the  initial  meeting. 

The  key  to  TQM  implementation  lies  in  leadership  by  DoD 
program  managers  and  by  their  contractors  and  suppliers  at  all 
tiers.  In  this  regard,  management  in  both  government  and  industry 
must  create  the  climate  which  will  foster  TQM  implementation  and 
ensure  that  their  personnel  are  properly  trained  and  motivated-  To 
initiate  this  process,  I  ask  that  you  take  the  following  actions: 

1.  Develop  your  plan  for  TQM  implementation.  Attachment  2 

contains  a  listing  of  some  preparatory  activities  that  may  be  taken 
to  start  TQM  implementation.  Your  plan  should  include:  (a)  how  you 
will  incorporate  TQM  into  the  acquisition  strategies  and  plans  for 
all  ma^or  system  new  starts;  (b )  how  you  will  apply  TQM  to  existing 
programs  and  identify  pilot.,  programs :  (c)  how  TQM  will  flow  down  to 
subcontractors  and  suppliers  relating  to  your  programs;  ' 

and  (d)  how  you  plan  to  apply  TQM  to  those  programmatic  and  other 
efforts  related  to  the  activities  of  knowledge  workers,  including 
management,  technical,  and  other  speciality  personnel"".  I  would 
like  to  review  your  implementation  plan  by  October  31,  1988. 

2.  Nominate  a  SES/Flaq  level  TOM  focal  point  for  coordination 
of  TQM  at  the  working  level. Your  nominee  should  have  a  broad 
perspective  of  acquisition. 


I  am  looking  forward  to  working  with  you  to  help  achieve  the 
extraordinary  promise  of  TQM. 


Attachments 
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Attachment  1 

OoO  Total  Quality  Management  (TQM) 

TQM  is  a  management  process  directed  at  establishing 
organized  continuous  process  improvement  activities,  involving 
everyone  in  an  organization  -  both  white  and  blue  col’ar 
personnel  -  in  a  totally  integrated  effort  toward  improving 
performance  at  every  level.  This  improved  performance  is 
directed  toward  satisfying  such  cross-functional  goals  as 
quality,  cost,  schedule,  mission  need,  and  suitability.  TQM 
integrates  fundamental  management  techniques,  existing 
improvement  efforts,  and  technical  tools  into  a  disciplined 
aoproach  focused  on  continuous  process  improvement.  These 
activities  are  ultimately  focused  on  increased  user/customer 


Attachment  2 


Preparatory  Activities  for  Total  Quality  Manager  ent(TQM)  Implementation 


To  begin  the  process  of  TQM  implementation,  initial  steps  should  be 
taken  to: 


become  acutely  aware  of  the  principles,  practices, 
techniques  and  tools  associated  with  TQM  (the  attached  reading  list 
will  be  useful). 

obtain  TQM-related  training  for  key  personnel  and  their 
subordinates . 

begin  a  dialogue  with  development/production  contractors 
and  potential  offerors  to  encourage  self-initiation  of  TQM  effort. 

examine  the  programs  and  processes  for  which  the  activity 
is  responsible  and  identify  ways  in  which  to  improve  them  using  the 
TQM  principles. 

establish  process  improvement  teams  within  Government  and 
contractor  organizations  to  pursue  improvements  aimed  at  increasing 
customer  satisfaction,  improving  performance,  reducing  cycle  time,  and 
reducing  cost. 

ensure  your  TQM  implementation  efforts  include  improving 
the  processes  involving  knowledge  workers,  including  management, 
technical,  and  other  speciality  personnel. 

begin  TQM  organizational  planning. 

identify  to  Program  Executive  Officers,  or  Service 
Acquisition  Executives,  those  contractors  who  are  qualified  and 
receptive  to  the  intensive  application  of  TQM  principles. 


Attachment  2  (Continued) 
Suggested  Readings 


The  key  to  effective  and  successful  implementation  of  TQM  is 
understanding  of  the  underlying  philosophy  and  theories  that 
support  continuous  process  improvement  efforts.  DoD  and 
industry  personnel  need  not  wait  for  formal  training  or 
indoctrination.  The  following  suggested  books  are  some  of  the 
best  in  the  field  of  continuous  process  improvement.  They  will 
provide  a  sound  basis  for  understanding  DoD's  TQM  philosophy  and 
vision. 

Crosby,  Philip  B.:  Quality  is  Free,  McGraw-Hill  Book  Company, 

New  York,  1979. 

Deming,  W.  Edwards:  Out  of  the  Crisis,  Massachusettes  Institute 
of  Technology,  Center  for  Advanced  Engineering  StudY,  Cambridge, 
Mass.,  1986. 

Feigenbaum,  Amand  V.:  Total  Quality  Control,  McGraw-Hill  Book 
Company,  New  York,  1983. 

Harrington,  H  James:  The  Improvement  Process,  McGraw-Hill  Book 
Company,  New  York,  1987. 

Imai,  Masaaki:  Kaizen,  Random  House,  New  York,  1986. 

Ishikawa,  Kaoru:  What  is  Total  Quality  Control?,  Prentice-Hall, 
Engilewood  Cliffs,  N.J.,  1985. 

Juran,  J.  M. :  Managerial  Breakthrough,  McGraw-Hill  Book  Company, 
New  York,  1964. 

Scherkenbach,  William:  The  Deming  Route  to  Quality  and 
Productivity,  Cee  Press,  Washington,  D.C.,1986. 

Schonberger,  Richard  J.:  Japanese  Manufacturing  Techniques:  Nine 
Hidden  Lessions  in  Simplicity,  The  Free  Press,  New  York,  1982. 

Townsend,  Patrick  L.:  Commit  to  Quality,  John  Weiley  and  Sons, 
New  York,  1986. 
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Appendix  E 


STRUCTURED  DECISION  MAKING 


STRATEGIC  MANAGEMENT  AND  THE 
MANAGEMENT  OF  PARTICIPATION 

by  Paul  H.  Richanbach  and  Frederick  R.  Riddell 
Institute  for  Defense  Analyses 


I.  INTRODUCTION 

Strategic  management  seeks  to  link  strategic  planning  with  decision  making  and 
implementation.  However,  the  literature  on  strategic  management,  perhaps  because  it  has 
evolved  from  strategic  planning,  does  not  adequately  address  the  questions  associated  with 
decision  making  and  implementation.  In  general,  the  strategic  management  literature  has 
failed  to  take  into  account  the  tools  of  decision  making  as  developed  in  the  organizational 
behavior  and  other  literatures.  Of  particular  significance,  in  our  view,  is  the  role  that 
participation  must  play  in  effective  decision  making  processes.  This  role  is  central  to 
effective  strategic  management,  particularly  during  periods  when  change  is  rapid,  because  it 
is  only  through  effective  participation  that  decisions  can  be  rapidly  communicated  and 
implemented.  Unfortunately,  the  literature  on  strategic  management  does  little  more  than 
pay  lip  service  to  the  role  of  participation. 

The  vast  majority  of  management  decisions  are  either  too  time  urgent  or  of 
insufficient  importance  to  warrant  full  scale  participatory  decision  making.  On  the  other 
hand,  strategic  management  deals  with  decisions  on  which  the  whole  success  of  the 
organization  depends.  Therefore,  it  is  one  area  of  decision  making  that  requires  full 
participation  and  a  careful  determination  of  who  should  participate  in  the  decisions  and  how 
that  participation  should  be  managed. 

One  of  the  features  that  most  distinguishes  the  current  business  environment  from 
that  of  only  20  years  ago  is  the  increased  rate  of  change.  A  successful  planning  process 
must  therefore  allow  an  organization  to  rapidly  develop  and  implement  an  agreed  upon 
series  of  actions  to  meet  these  changes,  and  to  provide  for  the  continuous  revision  of  that 
plan  as  the  environment  changes.  This  is  particularly  difficult  because  most  bureaucracies, 
large  and  small,  resist  change.  In  fact,  when  people  in  an  organization  say  they  cannot  do 
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anything  to  respond  to  a  changing  situation,  what  they  really  mean  is  that  they  do  not  know 
how  to  get  all  the  people  involved  to  take  the  actions  necessaiy  to  adjust  to  the  situation.  It 
is  not  so  much  that  people  resist  doing  the  right  thing,  but  rather  that  they  don't  see  how 
anything  can  be  done  without  some  risk  and  a  lot  of  effort,  thus  making  them  resistant  to 
change.  Organizations  require  management  processes  that  overcome  this  resistance  to 
change  and  provide  opportunities  for  people  to  do  the  right  thing.  The  careful  application 
of  certain  participatory  management  techniques  provides  a  means  for  doing  so. 

With  these  factors  in  mind,  we  define  strategic  management  as  a  continuous  process 
by  which  an  organization  identifies  a  set  of  long-term  objectives,  develops  a  strategy  to 
achieve  those  objectives,  agrees  upon  a  plan  to  implement  the  strategy,  and  sees  that  the 
actions  called  for  in  the  plan  are  carried  out.  The  key  to  strategic  management  is  not  only 
the  link  between  a  strategic  plan  and  its  implementation,  which  must  occur  much  faster  than 
in  years  past,  but  also  the  need  for  a  decision  making  system  into  which  important  new 
information  is  quickly  incorporated,  resistance  to  change  is  overcome,  and  in  which  there  is 
a  mechanism  for  following  up  on  the  implementation  of  decisions  already  taken.  To  put  it 
another  way,  planning  never  ends--it  must  be  imbedded  in  the  management  system  so  that 
plans  may  be  continuously  revised  as  circumstances  dictate. 

Strategic  management  may  be  seen  as  consisting  of  three  important  features: 

( 1 )  The  creation  of  a  documented  plan.  A  good  plan  is  a  necessaiy  centerpiece  and 
reference  document,  but  in  itself  is  not  a  sufficient  condition  for  the  success  of 
a  strategic  planning  process. 

(2)  Making  strategic  planning  an  integrated  part  of  the  management  system.  In 
order  to  be  successful,  a  strategic  plan  must  eventually  be  implemented  through 
existing  management  systems.  Plans  that  are  developed  by  off-line  planning 
staffs  or  outside  consultants  frequently  fail. 

(3)  Properly  managing  participation  in  the  planning  process.  Because  the 
participation  of  key  actors  in  the  organization  provides  the  necessary  linkage 
between  the  strategic  plan  as  a  document  and  its  implementation  through  the 
existing  management  system,  it  is  essential  that  this  participation  be  properly 
managed  at  each  step  of  the  planning  process. 

The  next  section  provides  a  brief  summary  of  current  thinking  on  strategic  planning 
and  management,  including  a  discussion  of  10  of  the  most  important  attributes  of  a 
successful  strategic  planning,  or  strategic  management,  system.  Section  III  begins  by 
asking  what  a  chief  executive  officer  should  do  if  he  or  she  wishes  to  introduce  strategic 
management  into  an  organization,  and  then  argues  that  the  key  to  implementing  an  effective 
strategic  management  system  is  to  be  found  in  an  understanding  of  how  the  CEO  should 
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manage  participation.  Section  IV  provides  some  specific  techniques,  which  we  call 
Structured  Decision  Making,  for  managing  participation  in  a  strategically  managed 
organization. 

II.  STRATEGIC  PLANNING  AND  STRATEGIC  MANAGEMENT 

Strategic  planning  is  most  commonly  thought  of  as  the  development  of  a  formal 
strategy.  Most  writers  on,  and  practitioners  of,  strategic  planning  devote  themselves  to  the 
development  and  exposition  of  particular  strategies  or  strategic  approaches  for  specific 
industries  or  markets.  A  smaller  but  still  substantial  group  of  authors  focuses  on  the 
appropriate  analytic  methods  for  successful  planning-what  questions  need  to  be  asked  and 
what  information  needs  to  be  obtained  in  order  to  develop  a  good  strategy.  The  three  most 
prominent  planning  concepts  developed  and  used  during  the  1970s  were  the  experience 
curve,  the  strategic  business  unit,  and  portfolio  planning.1  The  1980s  have  seen  the 
development  of  competitive  analysis,  or  what  is  sometimes  referred  to  as  the  industry 
structure  model.  Here  Michael  Porter's  work  on  "Competitive  Strategy"  appears  to  be 
seminal.2 

Organizations  use  the  the  strategies  and  strategic  approaches  available  to  them  to 
prepare  a  plan.  Often,  however,  the  strategic  planning  process  proceeds  little  further  than 
the  writing  of  this  plan  and  its  transmission  from  senior  management  to  the  rest  of  the 
organization.  As  is  well  known,  strategic  planning  developed  a  bad  name  for  itself  in  the 
1970s  precisely  because  consulting  firms  (and  internal  strategic  planning  staffs)  would 
develop  plans  that  firms  were  unable  to  implement.  The  firms  blamed  the  consultants  for 
writing  lousy  plans,  while  the  consultants  blamed  the  firms  for  their  inability  to  implement 
perfectly  good  plans.  It  finally  began  to  dawn  on  people  that  not  only  are  implementation 
issues  more  complex  than  originally  thought,  they  are  in  fact  central  to  the  success  of  any 
strategic  plan.  To  be  successful,  the  process  by  which  the  plan  is  developed  should  lead 
directly  to  its  implementation  within  existing  management  systems.  Thus  we  have  strategic 
management,  not  simply  strategic  planning. 


1  For  an  excellent  historical  review  of  these  planning  concepts,  see  Gluck,  Frederick  W„  "Strategic 
Management:  An  Overview,"  in  James  R.  Gardner,  el  al„  eds..  Handbook  of  Strategic  Planning, 
Wiley,  1986,  pp.  1.7-1.12. 

2  Porter,  Michael  E.,  Competitive  Strategy:  Techniques  for  Analyzing  Industries  and  Competitors,  The 
Free  Press,  New  York,  1980;  and  Competitive  Advantage:  Creating  and  Sustaining  Superior 
Performance,  The  Free  Press,  New  York,  1985. 
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Strategic  Management 

A  small  group  of  writers  and  practitioners  have  long  recognized  and  addressed  the 
difficulties  associated  with  the  implementation  of  strategic  plans.  Among  them  there  is 
widespread  agreement  on  the  basic  attributes  of  good  strategic  management  systems.  Ten 
attributes  are  listed  below,  but  the  first  three  are  of  particular  importance: 

1 .  The  strong  support  and  involvement  of  the  CEO  is  essential. 

2.  The  primary  responsibility  for  developing  strategy  belongs  to  those  who  must 
implement  it,  particularly  line  managers.  Their  participation  and  the  nature  of 
that  participation  are  of  critical  importance  to  decision  quality  and  ownership. 

3.  The  primary  role  of  staff  (non-line)  elements  is  to  act  as  facilitators  to  the 
planning  process;  it  is  not  to  take  control  of  the  process  or  ownership  of  the 
product. 

These  three  attributes  constitute  the  "first  principles"  of  strategic  management. 
Although  not  everyone  adheres  consciously  to  these  principles,  and  although  many 
practitioners  pay  them  little  more  than  lip  service,  their  validity  is  widely  accepted. 

First,  the  Chief  Executive  Officer  (CEO)  is  the  ultimate  strategic  planner  in  any 
organization.  Whether  through  his  or  her  actions  or  inactions,  the  CEO  is  ultimately 
responsible  for  the  strategic  direction  the  organization  takes,  and  the  active  participation  of 
the  CEO  in  the  strategic  planning  process  is  critical  to  its  success.3 

If  the  CEO  is  committed,  then  it  is  possible  to  gain  the  support  and  commitment  of 
the  organization's  other  senior  managers.  Senior  managers  in  this  context  refers  primarily 
to  line  managers,  those  with  direct  authority  and  responsibility  for  their  portions  of  the 
enterprise.  Their  commitment  is  essential  to  the  carrying  out  of  any  decisions  that  are 
reached,  and  their  knowledge  is  an  invaluable  input  in  the  planning  process. 

The  primary  role  of  planning  staffs  is,  or  should  be,  to  facilitate  the  strategic 
management  and  planning  process.  Such  staffs  might  perform  independent  analyses  in 
order  to  help  improve  the  quality  of  the  discussions  taking  place,  but  they  should  not 
normally  become  advocates  for  a  particular  position.  It  is  up  to  the  CEO  and  the  senior  line 


3  Although,  in  conformance  with  the  literature,  we  use  the  term  Chief  Executive  Officer  (CEO) 
throughout  this  article,  we  are  actually  referring  to  any  manager  with  clear  authority  over  an 
organization  or  a  part  of  an  organization,  whether  public  or  private.  The  principles  of  strategic 
management  are  applicable  to  division  managers,  project  managers,  and  so  on,  in  addition  to  the  CEO 
or  other  head  of  the  entire  organization. 
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managers  to  make  these  decisions.4  Unfortunately,  even  the  best  managed  organizations 
find  it  difficult  to  establish  planning  staffs  which  can  walk  the  thin  line  between  taking  an 
active,  but  neutral,  role  in  facilitating  the  strategic  management  process,  and  losing  their 
neutrality  by  becoming  advocates  for  a  particular  position.  When  the  latter  happens,  staffs 
begin  to  usurp  the  responsibilities  and  authority  of  line  managers,  who  then  lose  their 
confidence  in  and  commitment  to  the  management  process. 

In  addition  to  these  "first  principles,"  theorists  and  practitioners  are  in  broad 
agreement  on  a  number  of  other  aspects  of  strategic  management.  Seven  additional 
principles  are  outlined  here: 

4.  It  is  important  to  have  good  people  in  key  management  positions.  It  is  no  less 
true  for  being  a  truism  that  an  organization  can  be  no  better  than  its  people.5 

5.  Planning  must  include  resource  constraints  on  managers  that  force  them  to 
justify  and  make  difficult  decisions.  A  discipline  must  be  imposed  on  the 
resource  allocation  process  which  is  viewed  by  the  participants  as  systematic 
and  fair.6 

6 .  The  pace  of  change  requires  that  senior  management  develop  dynamic  strategic 
planning  processes.  Strategic  planning  is  often  used  in  an  effort  to  protect 
organizations  against  surprises  and  unwanted  change.  This  makes  it 
essentially  a  static  process.  Rather  than  view  instability  and  change  as  threats. 


4  There  is  widespread  agreement  on  the  appropriate  roles  of  CEOs,  line  managers,  and  planning  staffs. 
See,  for  example,  Hamermesh,  Richard  G.,  "Making  Planning  Strategic,"  Harvard  Business  Review, 
July-August  1986,  pp.  115-120;  Gray,  Daniel  H.,  "Uses  and  Misuses  of  Strategic  Planning,"  Harvard 
Business  Review,  January-Febmary  1986,  pp.  89-97;  Yavitz,  Boris  and  William  H.  Newman,  Strategy 
In  Action  (Free  Press,  1982);  Roach,  John  D.  C.,  and  Michael  Allen,  "Strengthening  the  Strategic 
Planning  Process,"  in  Kenneth  J.  Albert,  ed.,  The  Strategic  Management  Handbook  (McGraw-Hill, 
1983),  and  Gluck,  "Strategic  Management:  An  Overview."  Some  corporate  decisions,  such  as 
acquisitions  involving  new  products  or  markets,  may  rely  less  heavily  on  inputs  from  line  managers 
and  more  on  planning  staffs. 

5  See,  for  example,  Hambrick,  Donald  C.,  "The  Top  Management  Team;  Key  To  Strategic  Success,"  in 
Glenn  R.  Canoli  and  David  Vogel,  eds..  Organizational  Approaches  To  Strategy  (Ballinger,  1987);  and 
Rock,  Arthur,  "Strategy  vs.  Tactics  From  A  Venture  Capitalist,"  Harvard  Business  Review,  November- 
December  1987,  pp.  63-67. 

6  "If  a  plan  is  to  be  of  any  use  at  all _ it  almost  has  to  raise  tensions.  Moreover,  a  strong  position  has  to 

be  adopted  by  the  administration  to  ensure  that  some  progress  is  made  towards  making  real  strategic 
choices. .. [Planning  efforts. ..sometimes  seemed  to  be  the  concatenation  of  shopping  lists  from  various 
departments  which  did  not  eliminate  any  of  the  possibilities,  make  any  difficult  choices,  or  establish 
any  clear  consistent  patterns.  These  plans  may  have  made  everyone  happy  but  they  did  not  provide  a 
very  clear  guide  for  future  action."  Langley,  Ann,  "The  Roles  of  Formal  Strategic  Planning,"  Long 
Range  Planning,  Vol.  21,  No.  3,  June  1988,  p.  44.  Although  this  is  a  perfect  description  of  strategic 
planning  in  the  Department  of  Defense,  the  organizations  in  this  study  were  hospitals. 
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they  should  be  viewed  as  opportunities,  which  the  planning  process  can  shape 
into  advantages.7 

7.  Senior  management  should  refrain  from  imposing  goals  which  are  too  detailed; 
rather,  they  should  set  broad  but  clear  objectives  and  allow  (line)  managers 
further  down  in  the  organization  to  develop  meaningful  and  more  detailed  goals 
for  their  subordinates  which  are  consistent  with  the  top  level  objectives. 

8.  Strategies  must  be  carefully  communicated  to  the  rest  of  the  organization. 

People  need  to  understand  why  there  is  a  strategy,  why  there  is  this  strategy, 
and  why  and  how  it  should  affect  what  they  do. 

9.  Ideas  must  flow  up  as  well  as  down  through  the  organization  if  a  strategy  is  to 

be  viable.  There  are  a  lot  of  good  ideas  to  be  found  throughout  any  < 

organization  which  should  be  reflected  in  the  strategic  plan.  If  there  is  no 
mechanism  for  tapping  into  these  ideas,  then  it  is  difficult  to  gain  people's 
commitment  to  the  strategy.8 

10.  "Implicit"  strategies  should  be  recognized  and  used.  A  distinction  can  be  made 
between  strategies  which  are  deliberate  and  those  which  take  shape  with  little 
formal  direction.  In  many  cases  the  organization  already  has  many  elements  of 
an  implicit  strategy,  which  management  can  harness  by  molding  these  sub¬ 
strategies  into  a  higher  level,  overall  strategy.9 

An  organization  which  can  put  all  of  these  factors  together-and  the  consensus  is 
that  only  a  few  of  the  country's  best  run  organizations  have  been  able  to  do  so— is  one 
which  is  practicing  "strategic  management."  A  strategically  managed  organization  is  one  in 
which  strategic  planning  is  performed  proactively  throughout  the  organization  as  part  of  the 
expected  responsibilities  of  all  corporate  managers.  As  Roach  and  Allen  put  it:  1 

[S]trategic  planning  becomes  the  basic  management  style  on  every  level  of  the 
corporation  as  part  and  parcel  of  ongoing  operations...Strategic  planning  is  essentially  the 
business  of  all  managers,  whether  or  not  they  are  actually  called  into  the  ranks  of  strategic 
planners  per  se.  Every  manager's  experience  is  a  corporate  resource  that  the  best  strategic 

planners  will  put  to  good  use.10  ' 


< 

7  A  valuable  discussion  of  the  relationship  between  the  pace  of  change  and  the  development  of  strategic 
planning  processes  over  the  past  three  decades  is  contained  in  Gluck,  "Strategic  Management:  An 
Overview.” 

8  See,  for  example,  John  Roach  and  Michael  Allen,  "Strengthening  the  Strategic  Planning  Process." 

9  This  idea  is  most  closely  associated  with  the  work  of  Henry  Mintzberg.  See,  for  example,  "Crafting 

Strategy,"  Harvard  Business  Review,  July-August  1987.  * 

10  John  D.  C.  Roach  and  Michael  Allen,  "Strengthening  the  Strategic  Planning  Process,”  p.  7-16  and 
7-44. 
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Gluck  makes  the  same  point; 

What  distinguishes  these  companies  is  the  care  and  thoroughness  with  which  management 

links  strategic  planning  to  operational  decision  making  and  then  executes  its  plans...11 

III.  THE  MANAGEMENT  OF  PARTICIPATION 

Suppose  you  are  the  Chief  Executive  Officer  of  an  organization  and  you  want  to 
create  a  strategically  managed  organization.  You  realize  that  your  involvement  is  critical 
and  are  ready  to  commit  yourself  fully.  You  agree  that  your  line  managers  are  the  key 
players  in  the  organization,  and  that  good  strategic  management  must  be  structured  around 
them.  You  are  committed  to  ensuring  that  the  planning  staff  remains  a  small,  neutral  group 
which  seeks  to  facilitate  the  planning  and  management  process  without  usurping  the 
authority  of  the  organization's  line  managers.  What  do  you  do  now? 

Here  there  seems  to  be  a  gap  in  our  understanding  of  strategic  management 
processes.  Having  told  the  CEO  what  the  results  need  to  look  like— that  is,  what  the 
attributes  of  a  good  planning  process  are-there  is  nothing  which  tells  the  CEO  what  to  do 
to  put  such  a  system  in  place,  or  how  such  a  system  operates.  Many  writers  ignore  or  pay 
only  lip  service  to  the  critical  role  to  be  played  by  the  CEO,  and  little  has  been  written  on 
how  to  make  strategic  planning  an  integral  part  of  a  management  system,  so  as  to  achieve 
strategic  management.  If  line  managers,  as  the  primary  implementors  of  strategy,  are  the 
key  to  success,  then  strategic  planning  processes  must  be  designed  around  the  requirement 
for  their  participation.  Unfortunately,  this  recognition  of  the  importance  of  participation 
has  led  to  little  discussion  on  how  to  manage  such  participation  effectively. 

Decision  Making  and  Participation 

Participatory  management  is  not  a  new  concept,  and  the  role  that  participation  can 
play  in  decision  making  processes  has  received  a  great  deal  of  attention  from  management 
theorists,  psychologists,  organizational  behaviorists,  and  others  who  concern  themselves 
with  group  decision  making  processes.12  However,  there  appears  to  have  been  little  effort 
to  link  this  work  on  decision  making  to  models  of  strategic  planning  and  management, 
where  the  role  of  participation  is  often  mentioned  but  essentially  ignored. 


1 1  Frederick  W.  Gluck,  "Strategic  Management  An  Overview,"  p.  1,29. 

12  For  a  recent  and  excellent  example,  see  Vroom,  Victor  and  Arthur  Jago,  The  New  Leadership: 
Managing  Participation  In  Organization  (Prentice-Hall,  1988),  pp.  15-48. 
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One  important  lesson  from  the  extensive  research  on  decision  making  is  that  every 
decision  should  be  made  with  the  appropriate  involvement  of  the  "acceptance  set"  and  the 
"information  set."  The  acceptance  set  consists  of  those  people  whose  acceptance  of  a 
decision  is  required  before  it  can  be  successfully  implemented.  In  the  negative  these  people 
might  also  be  thought  of  as  the  resistance  set.  Little  will  change  so  long  as  these  key 
people  resist  taking  the  necessary  actions.  The  information  set  consists  of  those  people 
who  have  information  which  could  be  used  to  make  a  better,  a  higher  quality,  decision. 
When  making  a  decision  on  the  purchase  of  light  bulbs,  the  information  and  acceptance  sets 
may  consist  of  one  person--no  additional  participation  is  needed.  In  developing  a  plan  for, 
say,  the  introduction  of  a  new  product,  these  two  sets  contain  a  much  larger  number  of 
people. 

We  thus  face  a  situation  in  which  the  strategic  planning  and  strategic  management 
literature  pays  virtually  no  attention  to  the  central  role  played  by  participation  in  successful 
strategic  planning  and  management  processes,  while  the  organizational  behavior  literature 
on  participation  and  decision  making  has  not  been  applied  to  that  class  of  complex 
decisions  known  as  strategic  planning.  The  existence  of  this  gap  is  unfortunate,  because 
the  question  that  is  central  to  any  successful  strategic  management  process  is:  who  should 
participate  and  how  should  that  participation  be  managed? 

That  there  have  been  no  attempts  to  link  the  two  fields  of  strategic  management  and 
decision  making  may  be  due  to  the  fact  that  analyses  of  participation  are  typically  based  on 
the  implicit  assumption  that  decisions  are  already  being  made  within  an  existing  and 
functioning  management  system,  so  that  the  question  to  be  addressed  is  how  best  to  reach 
an  optimal  decision  within  that  system.  The  central  issue  with  respect  to  strategic 
management,  on  the  other  hand,  is--or  should  be--precisely  what  is  the  nature  and  function 
of  a  management  system  which  recognizes  the  importance  of  participation. 

Our  experience  with  developing  and  implementing  strategic  management  processes 
in  the  Department  of  defense  has  resulted  in  the  development  of  some  important 
connections  between  theories  of  participation  and  the  principles  of  strategic  management. 
We  have  developed  a  process  in  which  all  the  appropriate  participants--the  acceptance  and 
information  sets—are  included;  in  which  real  decisions  are  made,  not  just  a  consensus  that 
consists  of  pabulum  everyone  is  willing  to  agree  to;  and  in  which  decisions  can  be 
communicated  and  their  implementation  can  be  followed  up.  In  the  next  section  we 
describe  in  detail  the  process  we  have  developed  and  used  over  the  past  several  years, 
which  we  call  Structured  Decision  Making.  We  believe  that  it  is  techniques  such  as  the 
ones  we  suggest  for  managing  participation  that  are  crucial  to  successful  strategic 
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management,  and  should  therefore  be  the  focus  of  attention  for  management  theorists  and 
executives  alike. 

IV.  STRUCTURED  DECISION  MAKING 

The  three  most  important  aspects  of  good  strategic  management,  as  we  have 
argued,  are  the  role  of  the  CEO,  the  role  of  line  managers,  and  the  role  of  staffs  (see  above, 
Section  II).  The  initiation  and  operation  of  a  successful  strategic  management  process  can 
be  broken  down  into  three  key  elements,  based  on  these  three  attributes:  (a)  the  support  of 
top  level  management,  (b)  the  composition  and  activities  of  a  Steering  Group,  and  (c)  the 
role  of  the  facilitator.  We  also  add  a  fourth  key  element:  (d)  the  reco-ding,  communication, 
and  tracking  of  decisions. 

Strategic  management  requires  that  an  organization:  (1)  identify  a  set  of 
organizational  objectives,  (2)  develop  a  strategy  for  achieving  these  objectives,  (3)  agree  on 
a  detailed  implementation  plan  for  that  strategy,  and  (4)  see  that  the  actions  called  for  in  the 
plan  are  carried  out.  What  we  describe  is  a  process  by  which  these  actions  can  be 
successfully  carried  out. 

A .  The  Support  of  Top  Level  Management 

The  most  critical  element  for  success  of  strategic  management  is  that  the  effort  be 
initiated  and  supported  by  the  senior  executive  in  the  organization.  This  may  mean  the 
chief  executive  officer  of  the  organization,  or  the  head  of  a  division,  project,  or  other  sub¬ 
organization.  Without  his  or  her  active  interest  and  involvement,  individuals  in  the  rest  of 
the  organization  will  perceive—often  correctly-that  this  effort  will  come  to  naught,  because 
there  is  no  guarantee  that  the  results  of  their  efforts  will  be  accepted  and  implemented. 

This  top  level  involvement  begins  with  the  issuance  of  a  charter  for  the  Steering 
Group  (described  below),  describing  the  problems  and/or  issues  that  the  senior  executive 
wishes  to  have  addressed.  (These  issues  might  have  to  do  with  what  strategic  directions 
the  organization  should  take  in  the  years  ahead,  or  they  might  deal  with  more  specific 
issues,  such  as  what  to  do  about  rising  health  care  costs,  or  the  efficiency  of  the  R&D 
operation.)  This  charter  must  be  sufficiently  specific  so  as  to  help  the  Steering  Group 
focus  its  efforts.  At  the  same  time  it  must  be  broad  enough  so  that  the  members  of  the 
Steering  Group  do  not  feel  that  they  are  operating  under  excessive  restrictions  or  that  the 
results  of  their  efforts  are  a  foregone  conclusion--the  participants  must  be  able  to  take 
ownership  of  their  efforts. 


The  most  serious  problems  we  have  experienced  in  assisting  organizations  in  the 
Department  of  Defense  have  arisen  when  there  was  no  charter  and  the  senior  executive  was 
unwilling  to  issue  clear  guidance  on  what  he  wanted.  (This  is  a  particular  problem  in  the 
Defense  Department  because  authority  and  responsibility  are  so  diffuse.  It  is  often  difficult 
to  get  a  senior  DoD  executive  to  both  take  charge  of  a  problem  and  convince  others  to 
accept  his  authority.)  Under  these  circumstances,  Steering  Group  members  resist  doing 
any  work,  both  for  reasons  of  traditional  bureaucratic  politics  and  resistance  to  change,  and 
because  they  are  unconvinced  of  the  senior  manager's  commitment  to  the  exercise  and 
therefore  don't  want  to  waste  their  time  on  it 

B .  The  Establishment  Of  The  Steering  Group 

The  Steering  Group  will,  through  a  series  of  regular  meetings,  develop  a  set  of 
objectives  and  a  strategy  to  address  the  issues  presented  to  it  in  its  charter.  It  will  then 
develop  a  detailed  action  or  implementation  plan  for  the  organization  that  will  lead  to  the 
achievement  of  those  objectives.  Finally,  it  will  periodically  revisit  the  decisions  it  has 
made  to  see  how  well  they  are  being  implemented  and  to  determine  whether  the  passage  of 
time  and  events  requires  any  alterations  in  their  decisions.  This  activity  must  be  recognized 
by  the  members  as  being  an  integral  part  of  their  day-today  management  activities.  This  is 
not  a  "program,"  distinct  from  or  irrelevant  to  their  other  activities. 

In  selecting  the  members  of  the  Steering  Group,  the  senior  manager  must  satisfy 
three  criteria.  First,  the  membership  must  include  the  "acceptance  set."  This  typically 
means  the  senior  line  managers  in  an  organization,  along  with  other  key  staff  managers  as  < 

appropriate.  This  often  poses  an  interesting  problem  when  applied  to  our  work  with  the 
Department  of  Defense.  Not  only  is  there  often  disagreement  over  who  is  line  and  who  is 
staff,  but  many  managers  in  staff  positions  quite  literally  do  not  understand  the  distinction 
between  line  and  staff,  or  the  difference  in  their  responsibilities.  Second,  the  Steering  < 

Group  must  include  the  "information  set,"  those  people  whose  knowledge  of  matters 
pertaining  to  the  Steering  Group’s  charter  make  their  participation  essential  if  the  Group's 
report  is  to  be  of  high  quality.  Such  experts  may  come  from  within  the  organization,  or 
from  the  outside.  < 

Third,  the  Steering  Group  must  contain  no  more  than  17  people,  with  a  preferred 
limit  of  12.  Both  our  own  experience  and  that  reported  in  the  literature  make  clear  that 


( 
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groups  larger  than  this  are  too  large  to  function  effectively.13  Rather  than  increase  the  size 
of  the  Steering  Group,  sub-groups  are  formed  to  address  specific  issues,  with  instructions 
to  form  recommendations  and  develop  an  action  plan  to  implement  their  recommendations. 
It  is  the  Steering  Group's  responsibility  to  review  the  progress  of  the  sub-groups  and 
ultimately  to  synthesize  their  work  into  the  Steering  Group's  final  product  We  have  found 
that  one  or  more  members  of  the  Steering  Group  should  also  be  members  of  each  sub¬ 
group  in  order  to  ensure  proper  communication  up  and  down  the  line.  An  additional 
advantage  of  sub-groups  is  that  they  provide  a  mechanism  for  communicating  the  work  of 
the  Steering  Group  to  a  larger  number  of  influential  people  within  the  organization. 

The  goal  of  the  Steering  Group  is  to  see  that  all  important  issues  are  raised  and  fully 
discussed.  More  specifically,  this  means  that  conflicts  must  be  resolved  without  leading  to 
an  agreement  that  is  the  "least  common  denominator."  To  put  it  another  way,  what  is 
required  within  the  Steering  Group  is  conflict  without  animosity  that  leads  to  real  decisions, 
not  pabulum.14  Seeing  that  this  happens  is  one  of  the  key  roles  of  the  facilitator. 

C .  The  Role  Of  The  Facilitator 

The  Steering  Group  requires  the  use  of  neutral  facilitators.  Facilitators  have  a 
number  of  responsibilities.  First,  they  must  be  capable  of  providing  a  neutral  forum  for 
addressing  the  issues  described  in  the  charter  and  faced  by  the  organization.  Facilitators 
seek  to  assist  discussion  without  taking  positions  on  the  substantive  issues  on  which  the 
participants  are  presumed  to  be  experts.  This  includes  stimulating  and  moderating 
discussions  of  controversial  issues  so  as  to  ensure  positive  and  meaningful  outcomes,  as 
discussed  above.  If  internal  facilitators  are  used  (e.g.,  the  corporate  planning  staff),  they 
must  be  able  to  maintain  their  neutrality  in  the  eyes  of  the  other  participants.  In  order  for  all 
individuals  in  the  group  to  take  ownership  of  their  work,  they  must  not  feel  that  the 
particular  interests  of  the  person  or  organization  who  called  the  meeting  have  biased  the 
results  of  the  groups'  efforts.  Thus  the  importance  of  providing  a  neutral  forum  cannot  be 
overstated,  and  it  is  not  even  advisable  for  the  senior  manager  to  act  as  the  facilitator. 


13  See,  for  example,  Warfield,  John  N.,  Societal  Systems :  Planning,  Policy,  and  Complexity,  John 
Wiley  and  Sons,  New  York,  1976. 

1 4  Doyle  and  Straus  make  this  same  poi.it  by  drawing  a  distinction  between  consensus  and  compromise. 
Consensus  results  in  a  solution  everyone  can  live  with.  Compromise  results  in  everyone  backing 
down  a  little,  and  no  one  being  happy  with  the  final  result.  See  Doyle,  Michael  and  David  Straus, 
How  To  Make  Meetings  Work,  Jove  Books,  New  York,  1976. 
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The  most  obvious  role  of  the  facilitators  is  to  assist  in  the  conduct  of  each  meeting. 
They  do  this  by  helping  to  guide  the  discussions  in  a  way  that  allows  the  Steering  Group  to 
write  a  report  or  plan  that  meets  its  objectives,  as  stated  in  the  charter,  as  quickly  and 
efficiently  as  possible.  We  find  it  most  helpful  to  begin  drafting  a  final  report  after  the 
second  or  third  meeting  of  the  Steering  Group.  This  works  to  improve  the  quality  of  the 
eventual  report  by  getting  people  to  talk  about  the  important  issues  early  on,  and  it  also 
makes  it  easier  to  prepare  regular  progress  reports.  The  use  of  progress  reports  is 
discussed  in  more  detail  below.  The  facilitators  must  take  an  active  role  in  editing  and 
synthesizing  the  written  materials  prepared  by  Steering  Group  members.  This  includes 
assisting  the  Steering  Group  in  synthesizing  the  work  of  the  sub-groups  into  its  report. 

A  related  function  performed  by  facilitators  is  to  see  that  other  important  members 
of  the  organization,  who  are  not  on  the  Steering  Group,  are  kept  abreast  of  its  progress  and 
have  an  opportunity  to  provide  inputs  to  the  group.  The  facilitator  is  the  one  who  must  see 
to  it  that  the  issues  raised  and  decisions  made  by  the  Steering  Group  are  properly  recorded 
so  that  they  can  be  communicated  to  the  rest  of  the  organization,  and  so  that  decisions  can 
be  followed  up.  We  turn  now  to  this  issue. 

D.  The  Recording,  Communication,  And  Tracking  Of  Decisions 

One  of  the  biggest  problems  faced  by  all  decision  making  bodies  is  that  of  recording 
their  decisions  in  such  a  way  that:  (1)  all  the  participants  can  agree  after  each  meeting  on 
what  was  decided  and  what  issues  still  need  to  be  resolved,  (2)  people  outside  the  group 
have  enough  information  on  what  the  decisions  were  to  be  able  to  carry  them  out,  and  (3) 
decisions  can  be  reviewed  at  a  later  date  to  see  if  they  have  been  properly  implemented. 
Our  experiences  demonstrate  that  these  problems  can  be  solved  through  the  use  of  two 
important  meeting  tools,  a  computer  projection  system  and  a  continuously  updated  progress 
report. 

The  first  of  these,  a  computer  projection  system,  is  at  once  a  simple  and  powerful 
method  for  improving  the  efficiency  of  a  group's  work,  as  well  as  recording, 
communicating,  and  tracking  decisions.  As  discussions  are  held,  ideas  are  generated,  and 
decisions  are  made  during  a  meeting,  they  are  typed  into  a  computer  and  appear  on  a  large 
screen  at  the  front  of  the  meeting  room.  This  technique  offers  three  advantages  over 
traditional  techniques  such  as  the  taking  of  minutes,  or  the  use  of  overhead  transparencies 
or  flip  charts  to  record  ideas. 
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First,  it  serves  to  provide  a  clear  focus  for  the  discussions,  because  each  idea,  as  it 
is  being  discussed,  appears  on  the  screen  before  the  whole  group.  Second,  it  provides 
people  with  an  opportunity  to  clarify  for  one  another  the  precise  meanings  they  attach  to 
particular  words,  and  to  make  or  argue  about  changes  in  these  ideas  on  the  spot.  Thus, 
instead  of  arguing  at  the  next  meeting  about  what  was  meant  by  a  certain  phrase  or 
comment  that  appeared  in  the  minutes  to  the  last  meeting,  that  discussion  can  take  place 
right  away.  The  third  advantage  of  the  computer  projection  technique  is  that  the  results  of 
each  meeting  can  be  immediately  printed  and  distributed  to  the  participants.  In  addition  to 
minimizing  disagreements  about  precisely  what  decisions  were  reached  at  the  meeting,  this 
allows  people  to  begin  work  immediately  on  their  assignments  for  the  next  meeting,  and  to 
discuss  the  results  of  the  meeting  with  other  colleagues  who  are  not  on  the  Steering  Group. 

Finally,  this  system  provides  an  audit  trail  of  the  decision  making  process.  It  keeps 
a  record  not  only  of  what  decisions  have  been  reached,  but  the  reasons  for  those  decisions. 
Particularly  in  the  case  of  complex  problems,  understanding  the  reasons  behind  a  decision 
is  often  crucial  to  being  able  to  implement  it  in  the  way  in  which  the  original  decision 
makers  intended.  In  this  way,  it  is  also  valuable  in  allowing  senior  executives  to  track  how 
decisions  are  being  implemented. 

The  second  meeting  tool,  a  progress  report  that  is  continuously  updated  to  reflect 
the  deliberations  and  decisions  of  the  Steering  Group,  complements  the  use  of  the  computer 
projection  and  printing  system.  Using  the  information  already  recorded  during  the  Steering 
Group's  meetings,  the  facilitators  prepare  a  progress  report  which  the  participants  use  to 
keep  others  in  the  organization  informed  of  the  Steering  Group's  progress.  Not  only  are 
top  managers  kept  informed  in  this  way,  but  their  comments  or  concerns  can  be  relayed 
back  to  the  Steering  Group  and  incorporated,  as  necessary,  into  their  recommendations.  In 
addition,  the  use  of  a  common  set  of  meeting  records  (from  the  computer  projection  and 
printing  system)  and  progress  reports  means  that  the  participants  are  able  to  communicate  to 
others  a  consistent  story  about  what  they  are  doing.  Disagreements  are  made  clear  during 
the  meetings  and  during  the  preparation  of  the  progress  report,  where  they  can  be  resolved. 

V.  SUMMARY  AND  CONCLUSION 

Where  does  communication  and  decision  making  take  place  in  an  organization?  It  is 
only  a  slight  exaggeration  to  say  that  people  do  not  read.  Most  communication  takes  place 
verbally,  in  formal  and  informal  meetings.  The  techniques  for  Structured  Decision  Making 
that  we  have  outlined  here  emphasize  the  critical  importance  that  formal  meetings  play  in 
facilitating— or  failing  to  facilitate— communication  and  decision  making  within  an 
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organization.  The  nature  and  organization  of  the  Steering  Group,  the  role  of  the  facilitator, 
the  use  of  a  projection  system  to  record  information  during  meetings,  and  the  preparation  of 
a  progress  report  may  seem  at  first  to  be  details  too  insignificant  for  strategic  planners  to 
worry  about.  In  fact,  getting  these  things  right  is  crucial  to  the  establishment  of  a 
successful  strategic  management  process. 

We  began  by  suggesting  that  the  key  question  in  strategic  management  is:  who 
should  participate  and  how  should  that  participation  be  managed.  The  first  part  of  that 
question  was  relatively  easy  to  answer--it  is  the  acceptance  and  information  sets.  We  have 
therefore  concentrated  on  suggesting  answers  to  the  second  part  of  that  question.  When  a 
CEO  asks  how  to  implement  strategic  management,  we  believe  it  is  possible  to  provide  a 
more  complete  answer  than  has  previously  been  the  case.  Strategic  management  requires 
that  the  key  managers  in  the  organization  participate  in  a  process  of  identifying  objectives, 
developing  strategies  and  implementation  plans  to  achieve  those  objectives,  and  periodically 
reviewing  the  implementation  of  its  decisions.  It  is  a  continuous  process  of  review, 
implementation,  and  feedback.  Practically  speaking,  this  means  getting  all  the  right  people 
together,  convincing  them  that  what  they  are  doing  is  important  to  the  CEO  and  will  be 
used,  and  then  managing  their  participation  in  the  decision  making  process  effectively. 
Structured  Decision  Making,  although  not  a  cookbook  for  success,  suggests  some  proven 
techniques  that  may  be  of  value  in  a  wide  variety  of  organizations. 
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